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