Re: [請益] DB設計上為何不要都開NVARCHAR2(4000)
NVARCHAR和NCHAR的問題前面有高手講過,
我自己理解是搜尋效能問題,
但倒底效能會差多少,
我是沒有記,印象中差蠻多的,
至於你講的int問題,
應該是儲存空間的問題,
你同事用int還好,
我遇過有人不管什麼欄位都用nchar的,
性別也用nchar,日期也用nchar,金額也用nchar,
對他來說反正nchar也可以存"數字",
就什麼都用nchar...
想當然,後面接手的人就囧....
OK,不管是實際效用也好,"看起來"專業也好,
我分享一個我的另一種觀點,
那就是習慣問題,
因為我是對寫程式很龜毛的人,
而且我也認為龜毛的人適合寫程式或走IT,
我決定用nchar還是nvarchar,
或決定bit,tinyint還是int,
是因為我有認真的去思考過這個資料適合什麼形態,
能存多少筆,長度會到多少,搜尋效能為何...
這些我有想過,
所以我才會決定用什麼形態,
有想過,很小心的,很謹慎的去做決定,
這就是我想要的習慣,
nchar和nvarchar當下是不是真的有差那麼多不是重點,
重點是我若能保持這樣龜毛的習慣的話,
我可以減少很多可能會發生的問題,
我們都不是神,
不可能會預知到未來會有什麼變化,
我也不是什麼聰明的天才,
無法思考到很深很精細的地方,
身為凡人,
我唯一能做的,
就是養成龜毛的習慣來寫程式或管資料庫,
來盡可能的降低未來會發生的錯誤,
因為我知道若為了省一時的時間,
而導致發生問題的話,我要花更多時間去解決...
我是無法很詳細的解說底層運作的原理來解釋出用bit,tinyint,int會比一律用int好,
但我會用風險的角度來看,
未來資料"有可能"極為龐大,
未來技術"有可能"改變,
未來"有可能"有白目把不合理的資料塞入資料庫(例如把身份證字號打成13個字)
所以在設計欄位時,
就應該要儘可能的設計成貼近需求的狀況,
同理在寫程式我也是很龜毛,
程式碼有重覆的地方,
就儘量寫成迴圈或函數,
我一個檔案儘量寫在500行以內,
但就很多人只想花幾秒COPY PASTE,
久了就把一個檔案搞到上萬行,
我真的很討厭那樣,
我命名變數也是,
我有強迫症要把變數命名的有意義(沒人要求的話,我就用駱駝命名法),
此外,我看到有warning就會不舒服,
所以就希望自己寫的程式不要有warning,
但很多人就覺得可以跑就好,有warning沒關係,
然後compile就幾十個warning,還越來越多...
以上打那麼多,
只是我覺得龜毛的習慣很重要啦,
我不會覺得你太吹毛求疵,
我會覺得你幹得好
※ 引述《On1earth (小淺)》之銘言：
: 想藉這個主題問一下大家，
: 如果有一個欄位用tinyint，甚至是bit就足夠，會為了方便而全部使用int嗎？
: 一直以來我都是可以用bit就用bit、可以用tinyint就用tinyint，
: 但是近來看我同事全部都用int，其實系統沒那麼龐大，用int好像也沒怎麼樣，
: 現在有點動搖，在思考我是不是太過於吹毛求疵。
--
寫程式是一種信仰，
寫得出來是一種藝術，
寫不出來是一種哲學。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.118.1.45
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1408385884.A.FE7.html
→
08/19 02:23, , 1F
08/19 02:23, 1F
推
08/19 13:02, , 2F
08/19 13:02, 2F
→
08/19 15:33, , 3F
08/19 15:33, 3F
→
08/19 15:33, , 4F
08/19 15:33, 4F
→
08/19 17:06, , 5F
08/19 17:06, 5F
→
08/19 19:33, , 6F
08/19 19:33, 6F
→
08/19 23:54, , 7F
08/19 23:54, 7F
推
08/20 22:45, , 8F
08/20 22:45, 8F
→
08/20 22:45, , 9F
08/20 22:45, 9F
→
08/20 22:46, , 10F
08/20 22:46, 10F
→
08/20 22:46, , 11F
08/20 22:46, 11F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 8 之 8 篇)：