关于数据库设计时字段类型和长度的讨论,欢迎大家来讨论

[jxc]

对于任何字段长度都不应该过于小气,否则未知的变化会造成前后台都要修改

对于开关型字段建议number(1,0) 而不是varchar2(1),避免用户错误保存Y/N,而不是1/0,这样可能会引入大小写问题

对于数据字典编码字段,不要小气的确定为3位,最好统一为32位
经验证明,有时受从其它系统数据接入的影响,由于没有对照项,会直接保存原始值,而原始值一般都5-10位
统一为32位的好处是,可以考虑利用GUID来生成数据字典编码,这样在数据合并时非常有优势.

对于一般性录入字段,如:编号,轴号,车号,不要为了一时的"绝对"而设置确定的长度,最好统一成较优的长度,如32位!
如:车号最早是6位,没多久就改成了7位! 轴号开始为8位,但实际上有15位的轴号!轴承编号由10改为了20位

对于类似名称的字段: 如单位名称, 数据字典项目的名称等,最好再大一些,设成60位!

对于备注类型的字段,一般内容在30个汉字左右,所以推荐设置为100

对于长文本的字段,一般内容在200个汉字左右,推荐设置为1000

对保存SQL语句的字段(特殊情况,如配置传输条件等),至少要设置为2000,最大是4000

对于数字字段,除非精度要求,统一为number是个较好的选择
number默认精度为15位(整数位数+小数位数=15位,小数点位置任意),其它大数值也可以保存,但是采用的是科学计数法,有精度损失
用number,不指定精度的最大的好处是不限制数值的精度和范围
如果指定number(2,1),则存入的数值范围在-9.9 至 9.9之间,如果用户提出精度调整为2位,则需要修改数据库和程序!

对于日期型的就没有什么说法了

欢迎大家提出批评建议!!

[bobfang]

“对于数据字典编码字段,不要小气的确定为3位,最好统一为32位”这一点值得推敲。如果是varchar/varchar2类型，没问题，但如果是char则不好，太浪费空间了。而且这些字段一般都要建索引，这样也会使得每个索引项也占用过多的空间。

[jxc]

从占用空间考虑,统一定为32位的确有弊端,但是对于很多中/小应用系统,空间不是问题.

写这篇文档的目的是提高系统的冗余,降低后期系统维护的一种尝试.

[zealot_zk]

其实我觉得字段的定义主要还是要根据每个项目的要求，并考虑一定的扩充性，而且对于长度范围变化较大的字段最好都使用varchar/varchar2类型，而对于字典中的编码最好使用char型。另外，现在由于字典编码的修改是有一定限制的，不可能随意修改其长度，而且其长度增加又不复杂，所以建议还是规定的小一点可以大大节约空间，对备份等操作有好处。

[jxc]

oracle系统里尽量不要用char, 即使数据字典表的编码也不建议用char.

对数据字典编码的长度大家都会很敏感,因为它将影响业务表的大小.这里用32位,出于2个目的:
1. 接入其它系统的数据时,可能对方的信息不能转换为编码,如果字段宽度不够,势必要修改;
2. 编码系统主键考虑使用GUID,这样至少需要32位.

[jxc]

编码系统主键用GUID的缺点是从业务表数据中不好分辨业务信息,对数据分析需要关联数据字典表来查询.

[bzszp]

具体的长度设置还要参考用户的意见，一般来说 用户说这个字段一般也就10来个汉字，最好准备20多个汉字的空间。

[bzszp]

总的来讲，成本最小化是最终目的，同大量的维护成本相比，很多时候性能可以放在第二位。

[icedut]

来学习
留个记号

[bobfang]

我的理解应该是性能第一。从用户角度出发，最看重的是性能，如果性能差，再好维护也不会考虑；如果从厂家角度出发，如果性能差，导致用户索赔或退货甚至于买不出去，那么损失的是巨大的。

[jxc]

同意 bzszp(SongZip) 的观点!
成本最小化是最终目的，这也是我写这些内容的出发点.

因为用户的需求是易变的东西.
比如像铁路货车的车号,我们做系统的时候还是6位,没多久,铁道部竟然改为了7位,就为了这么1位的需求变动,我们的数据库和程序都要改动.也许有人认为给10位就够了,但是做数据库设计需要关注太多的业务细节并不是好事.

bobfang(匆匆过客)提出性能第一位的观点,我认为太武断了. 完成用户的需求,按期完成项目才是第一位的,否则你拿不到钱. 至于性能,也不是不重要,只是我们有足够的经验和能力完成哪些优化的设计和调整.

[hero_8080]

思考问题的角度不同，结论也不一样~~~
我很赞同bzszp(SongZip)和jxc(GameHeart的意见
用户需求来得快，变得也快，有时候还会反反复复
但是各个字段长了，会影响执行的速度，我建议一般的预留五至八位就差不多了

[mingxuan3000]

mark