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

看板Soft_Job作者 (lasa)時間9年前 (2014/08/15 16:41), 編輯推噓20(20推 0噓 58→)
留言78則, 26人參與, 最新討論串1/8 (看更多)
各位前輩，目前同仁們在討論一個問題，主要是關於資料庫設計方面， 根據Oracle的說明 NVARCHAR2 為長度可變動的欄位格式， 有個問題是，假設設計身分證的欄位， 當我把欄位設定成ID_NUM NVARCHAR2(10) 與 ID_NUM NVARCHAR2(4000) 就前提來看，只要我都只存10個字元，那個所占用的空間"應該"是一樣的， 如果說站在這個角度上，我將所有的欄位都設定成 NVARCHAR2(4000)， 那麼有沒有非常顯在的缺點 ? 目前是想像的到的 1. 無法從DB Schema看出長度限制 2. table fragmentation 3. 效能問題 還有其他潛在的問題嗎 ? 若是都把欄位設成NVARCHAR2(4000)的話呢 ? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.3.39.245 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1408092074.A.0D4.html
→
08/15 16:54, , 1F
這要看實作, 不過一般而言就是 good practice 而已
08/15 16:54, 1F
→
08/15 17:18, , 2F
對我來說，最大的缺點就是被人看到，會被冠上不專業
08/15 17:18, 2F
→
08/15 17:19, , 3F
對我來說"看起來"很專業蠻重要的。
08/15 17:19, 3F
→
08/15 18:03, , 4F
max row size限制.
08/15 18:03, 4F
→
08/15 18:57, , 5F
等你建index就知道了
08/15 18:57, 5F
→
08/15 19:10, , 6F
主管看到會火了你吧..
08/15 19:10, 6F
→
08/15 19:40, , 7F
固定長度的話 用NCHAR效能會比較好吧
08/15 19:40, 7F
→
08/15 20:43, , 8F
不是看起來專不專業的問題 感覺沒問題是碰的太淺
08/15 20:43, 8F
→
08/15 21:21, , 9F
滿討厭那種光是說別人不懂 或是 說別人不專業 太弱
08/15 21:21, 9F
→
08/15 21:21, , 10F
但是又不肯說出來問題到底是什麼 是哪裡的問題
08/15 21:21, 10F
→
08/15 21:22, , 11F
光是在那邊酸到底是有什麼意義?
08/15 21:22, 11F
→
08/15 21:55, , 12F
前面不就給key了嗎? 倒是你啥都沒講就想戰
08/15 21:55, 12F
→
08/15 21:55, , 13F
不然我改一下好了, 我道歉 一切只為了看起來很專業 end
08/15 21:55, 13F
推
08/15 22:00, , 14F
配置空間沒差,但client alocate memory沒那麼聰明
08/15 22:00, 14F
→
08/15 22:02, , 15F
fetch 資料時不會去算每一個row的實際大小
08/15 22:02, 15F
推
08/15 22:06, , 16F
變動長度開大不會影響儲存空間是對的
08/15 22:06, 16F
推
08/15 23:07, , 17F
今天有人在你身分證欄位輸入2000個字你會爽嗎?
08/15 23:07, 17F
推
08/16 00:00, , 18F
推kunchung
08/16 00:00, 18F
推
08/16 00:01, , 19F
一樣不喜歡alan3100態度
08/16 00:01, 19F
推
08/16 05:36, , 20F
client allocate memory是什麼意思? client又不知道DB設定
08/16 05:36, 20F
→
08/16 06:06, , 21F
同Tiida 的疑問
08/16 06:06, 21F
→
08/16 09:30, , 22F
推一堆文，結果沒人知道確切的答案....
08/16 09:30, 22F
推
08/16 09:42, , 23F
cache efficiency, sorting speed
08/16 09:42, 23F
推
08/16 11:40, , 24F
好問題，所以為了方便，我都是nvarchar(10)/(50)/(200)
08/16 11:40, 24F
→
08/16 11:41, , 25F
開欄位，不然要事先知道所以資料的max lengh 太累了
08/16 11:41, 25F
推
08/16 11:43, , 26F
我也想說都開nvarchar(50)/(200)真的效能有差嗎？
08/16 11:43, 26F
推
08/16 11:45, , 27F
至少書上說儲存空間（空間配置）是沒差的
08/16 11:45, 27F
→
08/16 11:47, , 28F
08/16 11:47, 28F
→
08/16 11:48, , 29F
缺點還蠻多的，不過我覺得對於"設計"的態度問題才嚴重
08/16 11:48, 29F
→
08/16 11:50, , 30F
設計 table 時對於你要存進資料庫的資料要有概念
08/16 11:50, 30F
→
08/16 11:52, , 31F
不應該只是資料庫放的進去，程式會跑就好
08/16 11:52, 31F
→
08/16 11:55, , 32F
實務上的經驗只有 comment 這種欄位會這樣開
08/16 11:55, 32F
→
08/16 11:56, , 33F
因為連 User 也不確定實際使用時會需要多大
08/16 11:56, 33F
→
08/16 11:56, , 34F
不過頂多也開個 1024 就夠了
08/16 11:56, 34F
→
08/16 12:07, , 35F
很多人都知道一堆小問題吧，但都不是大問題。
08/16 12:07, 35F
→
08/16 12:08, , 36F
效能、安全、空間、索引這些都會有小問題，但這些問題
08/16 12:08, 36F
→
08/16 12:09, , 37F
相對來說，都不如在客戶面前或上司面前黑掉。
08/16 12:09, 37F
→
08/16 12:11, , 38F
資料庫全部這樣開，影響最大的真的是自己的專業形象與觀感
08/16 12:11, 38F
→
08/16 13:02, , 39F
其實最明顯的問題是:為什麼你的主管會讓你這樣玩???
08/16 13:02, 39F
推
08/16 13:08, , 40F
明明就是存身分證，你開到四千是想怎樣
08/16 13:08, 40F
推
08/16 13:57, , 41F
技術面是沒有問題、硬體的性能也能支撐這個設計
08/16 13:57, 41F
→
08/16 13:58, , 42F
可是ID用來存身分證字號的欄位就有個資和格式的考慮了
08/16 13:58, 42F
→
08/16 13:59, , 43F
限定10個字元的欄位如果塞了不是10個字元的值
08/16 13:59, 43F
→
08/16 14:00, , 44F
又沒檢查不就成了系統裡的潛在漏洞?
08/16 14:00, 44F
推
08/16 21:16, , 45F
為什麼身分證字號要可以存超過10個字元？很簡單啊，你
08/16 21:16, 45F
→
08/16 21:16, , 46F
限定10個，然後有個外國人來掛號，沒台灣身分證怎麼辦?
08/16 21:16, 46F
→
08/16 21:17, , 47F
填護照號碼，超過10個字怎麼辦？切頭切尾，哪天又來另
08/16 21:17, 47F
→
08/16 21:17, , 48F
一個外國人護照號碼切完之後重複怎麼辦？主管：當初是
08/16 21:17, 48F
→
08/16 21:18, , 49F
誰亂規劃DB的？都沒想清楚？每個人都這種公務員心態怎
08/16 21:18, 49F
→
08/16 21:18, , 50F
麼做事啊！
08/16 21:18, 50F
推
08/16 21:19, , 51F
差別就是nvarchar(10)存不到4000的char 如果前端沒擋
08/16 21:19, 51F
→
08/16 21:19, , 52F
insert data的時候可能會報錯
08/16 21:19, 52F
推
08/16 23:40, , 53F
就像有人把db root帳號給web application使用，要說有
08/16 23:40, 53F
→
08/16 23:41, , 54F
什麼影響嗎？其實也沒有，只要不要遇到意外就好了
08/16 23:41, 54F
→
08/17 18:47, , 55F
原來有護照號碼長度是4000的,見識到了.
08/17 18:47, 55F
→
08/17 18:49, , 56F
哪人名/電話/地址/email,也可以用相同的理由囉.
08/17 18:49, 56F
推
08/18 21:43, , 57F
我認為有差 資料庫夠大夠多 有相似的欄位 在coding就需要
08/18 21:43, 57F
→
08/18 21:44, , 58F
ID 有很多種 假設統編 身分證 外國人代碼 還有相關的話
08/18 21:44, 58F
→
08/18 21:45, , 59F
只要有4 5種類似的延伸 coding就會很頭痛y
08/18 21:45, 59F
→
08/18 21:46, , 60F
尤其是 因為限制不能判斷檢核 資料就真的會爆
08/18 21:46, 60F
→
08/18 21:46, , 61F
加上甲方 如果 要debug 要申請手續一堆的話
08/18 21:46, 61F
推
08/18 21:47, , 62F
如果是內部用的系統的話，玩玩不要玩壞了其實沒差
08/18 21:47, 62F
→
08/18 21:47, , 63F
來個10次 在這種問題上 大概就不用做了
08/18 21:47, 63F
→
08/18 21:47, , 64F
但如果是要賣給客戶的，就燒好香，因為不管出了什麼錯
08/18 21:47, 64F
→
08/18 21:48, , 65F
客戶一要求檢視時，看到這個不先 %$#%$# 一下是不可能的
08/18 21:48, 65F
→
08/18 21:48, , 66F
因為 如果是自己開的當然自己知道 實際上是SD開的
08/18 21:48, 66F
→
08/18 21:48, , 67F
假設SD 都開這種 大概會準備找下一嘉公司吧
08/18 21:48, 67F
→
08/18 21:49, , 68F
對了 解bug 要算時間的 有的一小時1萬.... 何必增加
08/18 21:49, 68F
→
08/18 21:50, , 69F
超過罰錢 何必增加自己難度 有時候是維護需求
08/18 21:50, 69F
推
08/18 21:52, , 70F
500萬筆以上 50個欄位 還join來join去
08/18 21:52, 70F
→
08/18 21:52, , 71F
資料錯誤 就真的很難debug 超過罰錢都只能找藉口拜託
08/18 21:52, 71F
推
08/18 21:56, , 72F
做假資料時也會打錯 導致debug 完全看不出來哪裡有問題
08/18 21:56, 72F
→
08/19 22:22, , 73F
下一篇講一嘴神系統就射後不理, 這一系列看起來也冷了
08/19 22:22, 73F
→
08/19 22:25, , 74F
做最後補充,不改oracle設定全開4000 index大概只能1欄位
08/19 22:25, 74F
→
08/19 22:25, , 75F
如果你的系統連index都用不到就別再扯看起來很專業
08/19 22:25, 75F
推
08/23 09:18, , 76F
如果是不用程式存取的話就沒問題 要用程式的話 測試
08/23 09:18, 76F
→
08/23 09:20, , 77F
時 可能會要求測試到最大可能值 這時你就知道你的想法沒錯
08/23 09:20, 77F
→
08/23 09:22, , 78F
但只是給自己找麻煩吧
08/23 09:22, 78F
‣ 更多 returnbool 的文章
文章代碼(AID): #1JxSUg3K (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 returnbool 的文章
文章代碼(AID): #1JxSUg3K (Soft_Job)