Re: [問題] 關於字串壓縮演算法?MD5?URL?
→ 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
推
02/06 13:12, , 1F
02/06 13:12, 1F
→
02/06 13:17, , 2F
02/06 13:17, 2F
→
02/06 13:20, , 3F
02/06 13:20, 3F
→
02/06 15:38, , 4F
02/06 15:38, 4F
→
02/06 15:40, , 5F
02/06 15:40, 5F
→
02/06 15:43, , 6F
02/06 15:43, 6F
→
02/06 18:57, , 7F
02/06 18:57, 7F
→
02/06 20:01, , 8F
02/06 20:01, 8F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 5 篇)：