关于数据库设计时字段类型和长度的讨论,欢迎大家来讨论 “对于数据字典编码字段,不要小气的确定为3位,最好统一为32位”这一点值得推敲。如果是varchar/varchar2类型，没问题，但如果是char则不好，太浪费空间了。而且这些字段一般都要建索引，这样也会使得每个索引项也占用过多的空间。 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 其实我觉得字段的定义主要还是要根据每个项目的要求，并考虑一定的扩充性，而且对于长度范围变化较大的字段最好都使用varchar/varchar2类型，而对于字典中的编码最好使用char型。另外，现在由于字典编码的修改是有一定限制的，不可能随意修改其长度，而且其长度增加又不复杂，所以建议还是规定的小一点可以大大节约空间，对备份等操作有好处。 oracle系统里尽量不要用char, 即使数据字典表的编码也不建议用char.对数据字典编码的长度大家都会很敏感,因为它将影响业务表的大小.这里用32位,出于2个目的:1. 接入其它系统的数据时,可能对方的信息不能转换为编码,如果字段宽度不够,势必要修改;2. 编码系统主键考虑使用GUID,这样至少需要32位. 编码系统主键用GUID的缺点是从业务表数据中不好分辨业务信息,对数据分析需要关联数据字典表来查询. 同意 bzszp(SongZip) 的观点!成本最小化是最终目的，这也是我写这些内容的出发点.因为用户的需求是易变的东西.比如像铁路货车的车号,我们做系统的时候还是6位,没多久,铁道部竟然改为了7位,就为了这么1位的需求变动,我们的数据库和程序都要改动.也许有人认为给10位就够了,但是做数据库设计需要关注太多的业务细节并不是好事.bobfang(匆匆过客)提出性能第一位的观点,我认为太武断了. 完成用户的需求,按期完成项目才是第一位的,否则你拿不到钱. 至于性能,也不是不重要,只是我们有足够的经验和能力完成哪些优化的设计和调整. 思考问题的角度不同，结论也不一样~~~我很赞同bzszp(SongZip)和jxc(GameHeart的意见用户需求来得快，变得也快，有时候还会反反复复但是各个字段长了，会影响执行的速度，我建议一般的预留五至八位就差不多了 如果设置oracle11R2里的某个用户密码永久不过期？ Oracle 9i 增加数据库表空间时出错。 oracle 全文检索 表空间的磁盘转移问题 oracle中有没有像java finally一样的关键字啊。 oracle、db2、sql server高手进（有点难） 怎样一次输出一个记录变量中的所有内容？ 菜鸟求一道ORACLE题。内详 Oracle学习，求大神指点 关于full outer join的问题 关于字符串转换的问题 如何加密TNSNAMES.ORA
1. 接入其它系统的数据时,可能对方的信息不能转换为编码,如果字段宽度不够,势必要修改;
2. 编码系统主键考虑使用GUID,这样至少需要32位.
成本最小化是最终目的，这也是我写这些内容的出发点.因为用户的需求是易变的东西.
比如像铁路货车的车号,我们做系统的时候还是6位,没多久,铁道部竟然改为了7位,就为了这么1位的需求变动,我们的数据库和程序都要改动.也许有人认为给10位就够了,但是做数据库设计需要关注太多的业务细节并不是好事.bobfang(匆匆过客)提出性能第一位的观点,我认为太武断了. 完成用户的需求,按期完成项目才是第一位的,否则你拿不到钱. 至于性能,也不是不重要,只是我们有足够的经验和能力完成哪些优化的设计和调整.
我很赞同bzszp(SongZip)和jxc(GameHeart的意见
用户需求来得快，变得也快，有时候还会反反复复
但是各个字段长了，会影响执行的速度，我建议一般的预留五至八位就差不多了