[請益] DB設計上為何不要都開NVARCHAR2(4000)

作者: returnbool (Lasa)   2014-08-15 16:41:11
各位前輩,目前同仁們在討論一個問題,主要是關於資料庫設計方面,
根據Oracle的說明 NVARCHAR2 為長度可變動的欄位格式,
有個問題是,假設設計身分證的欄位,
當我把欄位設定成ID_NUM NVARCHAR2(10) 與 ID_NUM NVARCHAR2(4000)
就前提來看,只要我都只存10個字元,那個所占用的空間"應該"是一樣的,
如果說站在這個角度上,我將所有的欄位都設定成 NVARCHAR2(4000),
那麼有沒有非常顯在的缺點 ?
目前是想像的到的
1. 無法從DB Schema看出長度限制
2. table fragmentation
3. 效能問題
還有其他潛在的問題嗎 ? 若是都把欄位設成NVARCHAR2(4000)的話呢 ?
作者: uranusjr (←這人是超級笨蛋)   2014-08-15 16:54:00
這要看實作, 不過一般而言就是 good practice 而已
作者: DrTech (竹科管理處網軍研發人員)   2014-08-15 17:18:00
對我來說,最大的缺點就是被人看到,會被冠上不專業對我來說"看起來"很專業蠻重要的。
作者: LINGZ (肥兔小欽)   2014-08-15 18:03:00
max row size限制.
作者: alan3100 (BOSS)   2014-08-15 18:57:00
等你建index就知道了
作者: sabreur (無奈)   2014-08-15 19:10:00
主管看到會火了你吧..
作者: klandor (飛行翼)   2014-08-15 19:40:00
固定長度的話 用NCHAR效能會比較好吧
作者: alan3100 (BOSS)   2014-08-15 20:43:00
不是看起來專不專業的問題 感覺沒問題是碰的太淺
作者: robler (章魚丸)   2014-08-15 21:21:00
滿討厭那種光是說別人不懂 或是 說別人不專業 太弱但是又不肯說出來問題到底是什麼 是哪裡的問題光是在那邊酸到底是有什麼意義?
作者: alan3100 (BOSS)   2014-08-15 21:55:00
前面不就給key了嗎? 倒是你啥都沒講就想戰不然我改一下好了, 我道歉 一切只為了看起來很專業 end
作者: kunchung   2014-08-15 22:00:00
配置空間沒差,但client alocate memory沒那麼聰明fetch 資料時不會去算每一個row的實際大小變動長度開大不會影響儲存空間是對的
作者: GoalBased (Artificail Intelligence)   2014-08-15 23:07:00
今天有人在你身分證欄位輸入2000個字你會爽嗎?
作者: zo4j4 (happiness)   2014-08-16 00:00:00
推kunchung一樣不喜歡alan3100態度
作者: TllDA (踢打)   2014-08-16 05:36:00
client allocate memory是什麼意思? client又不知道DB設定
作者: osnq (又可以掛bbs了)   2014-08-16 06:06:00
同Tiida 的疑問
作者: thanksyou (謝謝你)   2014-08-16 09:30:00
推一堆文,結果沒人知道確切的答案....
作者: LoveBoat (ronin)   2014-08-16 09:42:00
cache efficiency, sorting speed
作者: odbc (odbc)   2014-08-16 11:40:00
好問題,所以為了方便,我都是nvarchar(10)/(50)/(200)開欄位,不然要事先知道所以資料的max lengh 太累了我也想說都開nvarchar(50)/(200)真的效能有差嗎?至少書上說儲存空間(空間配置)是沒差的
作者: fsz570 (570)   2014-08-16 11:47:00
http://goo.gl/kv4G08缺點還蠻多的,不過我覺得對於"設計"的態度問題才嚴重設計 table 時對於你要存進資料庫的資料要有概念不應該只是資料庫放的進去,程式會跑就好實務上的經驗只有 comment 這種欄位會這樣開因為連 User 也不確定實際使用時會需要多大不過頂多也開個 1024 就夠了
作者: DrTech (竹科管理處網軍研發人員)   2014-08-16 12:07:00
很多人都知道一堆小問題吧,但都不是大問題。效能、安全、空間、索引這些都會有小問題,但這些問題相對來說,都不如在客戶面前或上司面前黑掉。資料庫全部這樣開,影響最大的真的是自己的專業形象與觀感
作者: andymai (人生只有一次)   2014-08-16 13:02:00
其實最明顯的問題是:為什麼你的主管會讓你這樣玩???
作者: knives   2014-08-16 13:08:00
明明就是存身分證,你開到四千是想怎樣
作者: Himetsuki (琉璃雪月.咲夜)   2014-08-16 13:57:00
技術面是沒有問題、硬體的性能也能支撐這個設計可是ID用來存身分證字號的欄位就有個資和格式的考慮了限定10個字元的欄位如果塞了不是10個字元的值又沒檢查不就成了系統裡的潛在漏洞?
作者: Blueshiva (龍野南雲)   2014-08-16 21:16:00
為什麼身分證字號要可以存超過10個字元?很簡單啊,你限定10個,然後有個外國人來掛號,沒台灣身分證怎麼辦?填護照號碼,超過10個字怎麼辦?切頭切尾,哪天又來另一個外國人護照號碼切完之後重複怎麼辦?主管:當初是誰亂規劃DB的?都沒想清楚?每個人都這種公務員心態怎麼做事啊!
作者: KiroKu ( who)   2014-08-16 21:19:00
差別就是nvarchar(10)存不到4000的char 如果前端沒擋insert data的時候可能會報錯
作者: On1earth (小淺)   2014-08-16 23:40:00
就像有人把db root帳號給web application使用,要說有什麼影響嗎?其實也沒有,只要不要遇到意外就好了
作者: Lordaeron (Terry)   2014-08-17 18:47:00
原來有護照號碼長度是4000的,見識到了.哪人名/電話/地址/email,也可以用相同的理由囉.
作者: nfsong (圖書館我來了)   2014-08-18 21:43:00
我認為有差 資料庫夠大夠多 有相似的欄位 在coding就需要ID 有很多種 假設統編 身分證 外國人代碼 還有相關的話只要有4 5種類似的延伸 coding就會很頭痛y尤其是 因為限制不能判斷檢核 資料就真的會爆加上甲方 如果 要debug 要申請手續一堆的話
作者: abola921 (南港金城武)   2014-08-18 21:47:00
如果是內部用的系統的話,玩玩不要玩壞了其實沒差
作者: nfsong (圖書館我來了)   2014-08-18 21:47:00
來個10次 在這種問題上 大概就不用做了
作者: nfsong (圖書館我來了)   2014-08-18 21:48:00
因為 如果是自己開的當然自己知道 實際上是SD開的假設SD 都開這種 大概會準備找下一嘉公司吧對了 解bug 要算時間的 有的一小時1萬.... 何必增加超過罰錢 何必增加自己難度 有時候是維護需求500萬筆以上 50個欄位 還join來join去資料錯誤 就真的很難debug 超過罰錢都只能找藉口拜託做假資料時也會打錯 導致debug 完全看不出來哪裡有問題
作者: alan3100 (BOSS)   2014-08-19 22:22:00
下一篇講一嘴神系統就射後不理, 這一系列看起來也冷了做最後補充,不改oracle設定全開4000 index大概只能1欄位如果你的系統連index都用不到就別再扯看起來很專業
作者: shyart (ShyArt)   2014-08-23 09:18:00
如果是不用程式存取的話就沒問題 要用程式的話 測試時 可能會要求測試到最大可能值 這時你就知道你的想法沒錯但只是給自己找麻煩吧

Links booklink

Contact Us: admin [ a t ] ucptt.com