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

[littlethe (東周小星星)]

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
→ terrybob: 對自已負責，將來亦同。
推 YaMeiLo: 推跟你一樣，看到拿怪獸sql找我幫調效能覺得很白眼。
→ littlethe: 我前工作也是一直調作文級sql，裡面塞一堆子查詢又不
→ littlethe: 加where,看了很想罵人
→ NohohonZoku: 找看看內文錯幾個字:P
→ littlethe: 有錯字又沒關係,在PTT發文又不是我龜毛的地方=_=
→ viper9709: 推這篇~~觀念很好
推 On1earth: 謝謝大大回覆，因為出社會後就只待過這間公司，看的也
→ On1earth: 不多，所以想說藉這主題來請問版友們的做法，看了這篇
→ On1earth: 以及我發問的那篇，大家的做法還是會依照資料類型來決定
→ On1earth: data type，我知道該怎麼做了