看板 java 關於我們 聯絡資訊
→ pcyu16:有興趣討論的人不少 不過缺細節不知道怎麼討論 雖然... [下略數十字] 不過就由我起個頭,完全不理會原 po 自己重新起卦算命 [喂喂] ※ 引述《popcorny (畢業了..@@")》之銘言: : 標題: Re: [問題] 關於字串壓縮演算法?MD5?URL? ^^^^^^^^^^^^^^^^^^^^^^^ 順便酸一下,從標題我們就知道原 po 根本誤會「壓縮」二字的意思 MD5 跟 URL shorter 也算字串壓縮的話 那把該 column 的內容全部存 0 就好啦 \囧/ ______________________________________________________________________ 為了避免繼續算命下去,所以先作幾個前提假設: 1. ZIP 是最佳的字串壓縮演算法 aka 不要妄想設計一個新的字串壓縮演算法 2. 要儲存的是字串,大小不一長度不限 3. DBMS 得是 Oracle (昨天簡單查了一下,Oracle 提供的 datatype 很少?) 接下來就有幾個問題要解決: A. 要用哪個 datatype 才能解決問題 B. 儲存空間問題 C. 運算效率問題 (也就是,請不要用「效率」/「performance issue」簡單帶過) D. 能不能作 like 條件運算? (不考慮外掛 full text search engine) 最簡單直覺的方式: 還是用有 2000 char 限制的 nvarchar 之類的 datatype 字串丟進去之前先用 ZIP 壓縮過,取出來時用 UNZIP 解壓縮 A:未必能滿足,誰能保證壓縮完一定小於 2000 字? (不滿足假設 1) B:一定比較好 C:必要之惡 D:無法 search 所以基本上這個解法先天上就失敗.... : → Lordaeron:用BLOB TYPE基本上是沒有PERFORMANCE ISSUE的系統才用 02/06 12:02 雖然有點張飛打岳飛,但是 GAE.... [毆飛] 其實(後來)我不太懂為甚麼 Blob 會有 performance issue 或著說,到底是空間問題還是運算效率問題? : → popcorny:如果是為了效能改存檔我可以理解..但是如果是一定要存DB 02/06 12:08 : → pcyu16:有興趣討論的人不少 不過缺細節不知道怎麼討論 02/06 12:09 : → popcorny:那用CLOB應該也沒什麼不好吧.. 純粹以原po的角度 02/06 12:10 -- 錢鍾書: 說出來的話 http://www.psmonkey.org 比不上不說出來的話 Java 版 cookcomic 版 只影射著說不出來的話 and more...... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.135.202.140
maxpeter2100:關於效能問題 我也只是聽說clob很佔空間 dba不建議 02/06 13:12
pcyu16:一樓 大家在等你把問題跟限制描述清楚... 02/06 13:17
pcyu16:不然你這樣東一句西一句 又沒有講原因 大家會很困擾.. 02/06 13:20
Lordaeron:jdbc 連線,單筆一來, 一回, 就有資料了,若含BLOB 02/06 15:38
Lordaeron:則另外要開一條線來取得 blob field 的值 02/06 15:40
Lordaeron:所以才有varchar field由255開始放大的情況 02/06 15:43
cyclone350:我也聽主管說 blob 跟 clob 最好別用,會很慢 02/06 18:57
Lordaeron:不用主管說了, ORACLE 自己就說了. 02/06 20:01