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

[Lordaeron (Terry)]

※ 引述《returnbool (lasa)》之銘言：
: 各位前輩，目前同仁們在討論一個問題，主要是關於資料庫設計方面，
: 根據Oracle的說明 NVARCHAR2 為長度可變動的欄位格式，
: 有個問題是，假設設計身分證的欄位，
: 當我把欄位設定成ID_NUM NVARCHAR2(10) 與 ID_NUM NVARCHAR2(4000)
: 就前提來看，只要我都只存10個字元，那個所占用的空間"應該"是一樣的，
: 如果說站在這個角度上，我將所有的欄位都設定成 NVARCHAR2(4000)，
: 那麼有沒有非常顯在的缺點 ?
: 目前是想像的到的
: 1. 無法從DB Schema看出長度限制
: 2. table fragmentation
: 3. 效能問題
: 還有其他潛在的問題嗎 ? 若是都把欄位設成NVARCHAR2(4000)的話呢 ?
問題主要不在DB 哪一邊, 問題主要在CLIENT 這一邊, 和網路這一邊.
你就是用偉大的ORM 來寫CLIENT, 但你從你的TABLE SCHEMA
, 將無法準確得知一筆資料最多佔多少資源. 從而無法好好的
了解你的程式的限制. 再來, 網路哪一段, 也有同樣的問題.
你將答不出任何頻寬的需求.
當然, 也會像有人說的, 以上都是小問題. 畢境佔多少資源問題, OMM 就加大MEMORY
加大了變慢, 就加CPU, 當掉就就要USER 重開囉.
而頻寬問題, 不夠就加大囉, 100MB, 不夠就1GB, 交換機,ROUTER 全都換,
也沒多少錢.
程式怎麼規畫, 怎麼寫, USER 買不買單就好.

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.243.113.137
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1408173488.A.D45.html
→ uranusjr: 我個人是從來沒看過有 ORM 需要知道這個的; 動態字串
→ uranusjr: allocation 不是基本的嗎？
→ shadow0326: ya 所以NoSQL就是潮 grid就是潮
→ Lordaeron: 基本啊,所以台灣人寫的JAVA是無法7X24. 玩具是沒問題的
→ Lordaeron: 當你連自已的程式的反應都不知時,這要算PROGRAMMER?
推 cyclone350: 資料限制及驗證應該要從文件知道吧? XD
→ Lordaeron: 咦,文件呢,連IBM/ORACLE 等廠出的文件都沒100%,台灣?
→ Lordaeron: 再來,文件跟你說10,TABLE 是4000,你寫程式的,會敢開10?
推 liddle: 微軟系的Linq to xxx 可都是會用資料形態,長度 產生 code
→ liddle: j 系也有靠資料庫資料形態長度產code的工具，然後一次就把
→ liddle: 整個基本資料傳遞架構長好,還包前端js驗證。要是碰上這種
→ liddle: 一律開nvarchar 4000的狀況，真的不用搞軟體工程了