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好像也没怎么样，
: 现在有点动摇，在思考我是不是太过于吹毛求疵。