请教各位老虾！关于仓储系统的冗余字段设计

Question

关于仓储系统的方案设计，以下为现有仓库表的设计（部分表）：TAB/装车单：
字段：（装车单号，仓库ID，仓库编码，仓库名称，...创建人NAME，创建时间，修改人NAME，修改时间...）TAB/装车单明细表：
字段：（装车单号，货物ID，货物名称，...创建人NAME，创建时间，修改人NAME，修改时间...）
TAB/采购单：
字段：（采购单号，...创建人NAME，创建时间，修改人NAME，修改时间...）TAB/采购单明细表：
字段：（进货商ID，进货商NAME，采购部门ID，采购部门NAME，...创建人NAME，创建时间，修改人NAME，修改时间...验货人NAME，验货时间）首先这个不我设计的，我觉那个人这样的设计的好处就是为了查询方便（不用做关联查询嵌套查询什么的就能获得要的数据），但是一旦部门名称或者管理员名称（即便可能不修改 但不是绝对的）等等会影响到所有使用这些数据的表。
。
我的解决方案我看到这个库时候感觉里面太多太多的表都都是这样的，举个最明显的例子，创建人NAME 好多表都存的是 管理员的NAME 而非ID。我觉的除了把管理员NAME之类的删除，都换成外键。除此 像装车单里的仓库编码、仓库名称、等；装车明细表里的货物名称；采购单明细里的采购部门NAME，进货商NAME都统统删除 只保留引用的外键ID进行设计之所以这样修改是为了解决数据冗余问题，但后期在查询数据时候会涉及更多的嵌套查询关联查询才能解决。不知道各位老虾怎么看我这样的处理方案或者给个更好的意见，多谢
===============================================================================

Answer 1

1.  创建人NAME 保存到数据库,不明知,给人的感觉很外行.略懂的人都不会存储名字,存储员工的ID是明智.
2.  创建人和修改人虽然是与员工表在关系,但不需要建外键关系.如果建太多了,也没有这个必要.
3.  装车单的主表和明细表,可以说只需要主表有:创建人ID，创建时间，修改人ID，修改时间,子表不需要有.如果是特殊数据,那么子表也要有创建人ID，创建时间，修改人ID，修改时间.如财务数据
4.  子表与主表之间要创建外键约束关系.

Answer 2

“除此 像装车单里的仓库编码、仓库名称、等；装车明细表里的货物名称；采购单明细里的采购部门NAME，进货商NAME都统统删除 只保留引用的外键ID进行设计”那您是同意切赞同我这样的设计喽 呵呵

Answer 3

你还 在请问一下 如果进行列表 GRIDVIEW涉及好多字段的数据显示问题（多表组合显示，因为都是外键 所以要通过外键调取需要的数据，也许会很多）除了 利用存储过程进行查询出总结果和利用程序的嵌套查询或整理视图 还有其他方法么

Answer 4

“除此 像装车单里的仓库编码、仓库名称、等；装车明细表里的货物名称；采购单明细里的采购部门NAME，进货商NAME都统统删除 只保留引用的外键ID进行设计”那您是同意切赞同我这样的设计喽 呵呵
\不仅是赞同,其实大家都是这样做的.如果都保存Name进入采购部门NAME,进货商NAME都等,今天我不说,也总有一天有人会笑你们这样设计.

Answer 5

我能明白楼主的意思。其实，你对于表的修改意见，是对的。因为，关系数据库系统，在设计时，有所谓3NF，一般都要达到这个第三范式，这样能够减少数据的冗余。而且，实际上不仅能够减少冗余，而且这样做的好处是由于是通过外键来引用基表的id，修改也方便了，比如，当你的仓库名称变化了，你只需要去修改，这些业务表所引用的，基表里面的仓库名称。而你们公司现在的系统，如果你有10个业务表，都有仓库名称这个字段，一旦只要有一个仓库的名称变化了，那么你就得通过仓库编号，来连接基表，然后再update这10个表的仓库名称，那是非常麻烦的。应该说，你们公司现在系统的数据存储方式是采用了反向规范化，也就是冗余化存储。你希望采用规范化，而你们公司原来的系统采用的是范规范化。规范化的好处上面说了，就是减少数据冗余，修改非常容易。
而反向规范化的好处，就是不用子查询，或者关联多的表，查询的性能会好。总结：
我觉得到底采用哪种方式，这需要你自己权衡，如果你的系统，很少有更新仓库名称，也就是很少更新这些基表数据，那么为了提高查询的性能，而且也不用每次写查询，关联N多基表，那么就还是采用原来的方式。这种方式，在互联网的应用中比较多，传统的业务用的不多。如果系统中会更新这些仓库名称，那么还是建议采用外键id的方式，来修改这些表的设计，当然啦，语句可能得写的比较复杂，因为我原来的公司就是都采用外键id的，由于这种外键很多，公司设计了一个字典表，比如：dict_table 里面存放了几乎所有的外键id，所引用的id，那么我们公司有一个store表，里面有一堆的id，上面渠道id，公司id，组织id，经销商id，层级id，性质id等，于是乎，为了取得这些客户的渠道、公司、组织、经销商、层级、性质，就得关联dict_table 至少6次，也就是select 字段列表
from store 
left join dict_table 
left join dict_table 
left join dict_table 
left join dict_table 
left join dict_table 
left join dict_table 就是这样，经常一个查询，得关联10-15个表左右，语句写的非常复杂。所以，呵呵，最后还是得楼主，按照你们公司的特殊情况，业务特点，来选择，到底是去除冗余，或者是去除部分冗余。