推 lovdkkkk: 推 08/16 21:53
推 sing10407: 推 08/16 22:56
推 Abbee: 推 08/17 06:58
※ 引述《returnbool (lasa)》之銘言：
: 各位前輩，目前同仁們在討論一個問題，主要是關於資料庫設計方面，
: 根據Oracle的說明 NVARCHAR2 為長度可變動的欄位格式，
: 有個問題是，假設設計身分證的欄位，
: 當我把欄位設定成ID_NUM NVARCHAR2(10) 與 ID_NUM NVARCHAR2(4000)
如果我沒搞錯， NVARCHAR2 是用來存 unicode 資料的，如果只是要存
台灣身分證字號應該不需要用到這個吧？
: 就前提來看，只要我都只存10個字元，那個所占用的空間"應該"是一樣的，
其實想想看如果你要實作把你的 row 存在檔案裡面，該怎麼做，就可以知
道佔用空間會不會一樣，會不會有其它缺點產生。
一般這種非固定長度欄位，會多用一些空間來儲存該欄位的長度，用來
計算下一個欄位儲存的地方。我不知道 Oracle 怎麼處理，但是 MySQL
的 MyISAM 如果宣告的最高長度低於 256 bytes ，會用一個 byte ，
超過的話，則會有兩個 bytes 。這樣 10 跟 4000 就會有差異了。
當然不能排除 Oracle 用固定的 k bytes 來做這部分，這樣就沒差異。
: 如果說站在這個角度上，我將所有的欄位都設定成 NVARCHAR2(4000)，
: 那麼有沒有非常顯在的缺點 ?
: 目前是想像的到的
: 1. 無法從DB Schema看出長度限制
: 2. table fragmentation
: 3. 效能問題
: 還有其他潛在的問題嗎 ? 若是都把欄位設成NVARCHAR2(4000)的話呢 ?
想想看如果有個狀況（ bug 或是輸入錯誤沒檢查到等等），導致某筆資料
長度超過 10 ，那就跟資料結構課裡面會看到的，你要在一個陣列中間插入
一個值，那麼後面的資料都要往後移動一格，對系統會有什麼樣的衝擊？
要記住磁碟存取是很慢的。到時候修正的時候，是不是也會有類似的狀況
發生？
當然以上的說明有點簡化，有些資料庫會有特殊技巧來處理這些問題，主要
目的是建議碰到類似問題，想想底層實作部分，可以幫助你分析選擇的利與
弊，然後做出 Z>B 的選擇。
--
Some people are born on third base and go through life
thinking they hit a triple.
- Barry Switzer
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.126.251.25
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1408195230.A.5AF.html