做了一个外贸行业的订单表43个字段，各位会不会觉得太过分了。。(希望有经验的人士进来指点一下)

Question

我在处理一个外贸订单表的过程中，就订单表产生了40多个字段，
这是一个读取频繁的表，这么多个字段肯定会对读取效能产生影响，
我怀疑我数据库设计有误，现在列出以下信息，大家帮忙参考一下。
1.自动编号 
2.订单编号
3.客户冠名
4.客户实体
5.订单场景
6.下单日
7.跟单人
8.负责人
9.简述
10.出货区间1
11.出货区间2
12.预定出货当日
13.供应商编号
14.厂家信息编号
15.厂家客人编码 (客人给每个厂家编码会有变动，每个订单必须记录)
16.受益人编号
17.出产国
18.订单季节编码
19.订单收款协议
20.订单收款协议附加简述
21.订单的进度总状态编码信息
22.订单进度状态基本描述
23.订单总数量
24.订单总装箱数
25.订单总材积
26.订单总价格
27.订单总卖价
28.订单总毛重
29.订单总净重
30.订单20尺柜数量
32.订单40尺柜数量
33.订单40尺高柜数量
34.订单45尺柜数量
35.订单备注信息
36.数据排序位
37.数据备注位
38.订单出货港口
39.订单目的港口
40.数据创建日期
41.最后修改日期我知道里面一定有数据冗余
希望各位给我指点一下。
盼复

Answer 1

把经常更新和比较少更新的字段分开

Answer 2

要么就把信息相似的单独列出,制成一个表,然后用其ID返回即可!可以考虑下!

Answer 3

这个很正常....一点都不多....我以前的做过一个企业综合统计表也有五十来个字段..没办法....省不了的....你想想看....少哪个字段...表的内容信息就不完整了..对吧.

Answer 4

确实不是很多啊，原来在学校做一个简单的成绩管理都要二三十个字段

Answer 5

正常，据不可靠信息，中国移动的数据库中，大客户数据表，有70多个字段。。

Answer 6

我觉得有点问题:
用户(或厂家)信息应该和订单分开,一个用户可以有多个订单,一个负责人也可以负责多个订单,两个表可以通过订单编号来关联,最好再添加一个备注字段,用来存放一些不规则的内容.

Answer 7

楼上的几位犯了一个小小的错误:自己作过的不代表就一定是好的,或许你们只是犯了相同的错误而已. 更不要以为大公司有这样的例子存在,就一定也适合你.
要知道很多大公司也是从小公司过来的,或许小公司的时代还能凑合,慢慢承诺工了大公司,小问题就成了大问题,据我所知,很多大公司为了解决数据库结构上的改变而付出了巨大的代价.
再者,大公司用的服务器也不是我们一般的PC所能比拟的,数据库机构差一点,或许在它们那里跑没有问题,在你这里就会是个大问题了.我的建议是:在你的数据库结构还没有最终定好之前,多花点力气在字段和表格的规划上吧.
或者你觉得当数据库里有了数十万条记录,并且整个程序都建立在这个数据库结构之上,更痛苦的是业务部门无法停止业务等你修改程序,你会有时候在一个晚上全部重写代码并且将已有记录转换成新的格式...一口气说上面的这个长句,有点憋,我只是想让楼主知道数据库的结构在整个项目中扮演的是地基的角色,等你房子造好了,人都住进满的时候,你却发现地基有问题,呵呵,一定会是一个很黑色的幽默吧?说那么多,只是因为我有过这样的教训,所以想给楼主一个比较负责的回答.

Answer 8

呵呵...楼上的说的对啊...其实可以进行细化.分成 用户信息表\负责人信息表\订单信息表  等等..表与表之间通过关键字连接....读取的时候通过视图操作....如果单单操作某一项信息,比如用户信息,只用对相应的用户信息表操作...而不用像以前一样修改大表....

Answer 9

不过我做过的那个....综合统计表确时有五十来个字段...这也是没办法的事情....因为里面所有的项和我们已经设计出来的细表都毫无干系,在项目在验收后,客户临时突发奇想让加上的,于是只有将这些莫明其妙的字段都放在一个表里...形成了一个杂表,并且综合统计表不常用....所以就没有细化..否则反而繁琐了....