→ alan3100: 我到是很想看你怎樣解釋不影響專案還會加速工時 08/18 12:49
→ alan3100: 示範一下前面程式花很小的功克服需要上小時的full scan 08/18 12:57
推 MephistoH: 就像我,推薦主管新東西,好用又省事,反而黑掉... 08/19 10:32
→ MephistoH: 最近反而高層不滿主管的舊思維,整個部門都黑掉 08/19 10:33
※ 引述《returnbool (lasa)》之銘言：
: 各位前輩，目前同仁們在討論一個問題，主要是關於資料庫設計方面，
: 根據Oracle的說明 NVARCHAR2 為長度可變動的欄位格式，
: 有個問題是，假設設計身分證的欄位，
: 當我把欄位設定成ID_NUM NVARCHAR2(10) 與 ID_NUM NVARCHAR2(4000)
: 就前提來看，只要我都只存10個字元，那個所占用的空間"應該"是一樣的，
: 如果說站在這個角度上，我將所有的欄位都設定成 NVARCHAR2(4000)，
: 那麼有沒有非常顯在的缺點 ?
: 目前是想像的到的
: 1. 無法從DB Schema看出長度限制
: 2. table fragmentation
: 3. 效能問題
: 還有其他潛在的問題嗎 ? 若是都把欄位設成NVARCHAR2(4000)的話呢 ?
這問題我想很多人都知道"小"問題，但卻說不出有什麼影響重大的問題。
效能、安全、空間、索引(index)、資料顯示這些都會有小問題，
但都有辦法事後克服，甚至很容易直接就從較前面的程式邏輯解決。
即使未來發生問題，也有辦法修改。
相對於以上的各種缺點，
其實最嚴重的反而是人情世故產生的缺點。
客戶或似懂非懂的長官看到你這樣設計資料庫。
你即使努力解釋不影響專案，甚至會加速工時等正面方向，你還是會黑掉。
他們的既定印象是，你是個工作態度隨便，不專業的人。
然後這種印象會跟者你好幾年，甚至是一輩子。
有時候還會被當職場笑話拿來說。
這不是像程式與資料庫一樣，想改就能改的。
這種人情世故的大缺點，相較網路上所提到的各種缺點，絕對是嚴重太多了。
不要以為技術考量永遠是最重要的。
人情世故永遠凌駕於技術阿。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.43.77.218
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1408163368.A.BF0.html
※ 編輯: DrTech (114.43.77.218), 08/16/2014 12:31:49