关于数据库设计的有关问题，
关于数据库设计的问题，请指教！！
最近正为客户做套联锁仓库管理系统：所有的入库业务可以分为如下几类：采购入库，配送入库，调拨入库，加工入库，盘盈入库。当前有两种思路：1.对于入库操作只用两个表，trr_insert,和trr_insertdetail,在trr_inert中加入入库类型列：intype,来区别不同的入库方式。2,针对不同的入库类型，分别设计不同的表.如：trr_insert1和trr_insertdetail1，trr_insert2,和trr_insertdetail2，trr_insert3,和trr_insertdetail3。
以上两种方式，哪一种更合理？请指教！
------解决方案--------------------
各有各的好，
第一种方法所有数据都在一起，统计检索比较便捷适合各种各样的检索方式，适应当类型多种多样并且何以任意定制时；我就遇到所有仓库入库数据是存储在一起的，改动单号等非常麻烦，改动比较多；
第二种方法数据单独存储，检索效率比较高，检索上不太灵活，也许有时候需要视图来组合；适合每种类型存储类型固定，每种类型数据格式存储上变化比较大；如果不大还是不要分开；
个人认为多数人会采用第一种
------解决方案--------------------
1楼说的在理，如果各入库类型数据结构上没有差异的话，还是不要分开好了。你20家分店，每家分店都有不同的入库业务类型，这样分开入表，检索每个分店又得连多表
------解决方案--------------------
数据不是相当多，简单些好，不要分开好
------解决方案--------------------
我肯定要选第一个方法
------解决方案--------------------
用每一种方式，在统计查询方面比较方便的，而且20多台电脑操作一个表，没有什么问题的，我们做的时候，所有的单据（包括进仓、销售、调拨、盘点）都在同一个主表、从表的，30多台电脑同时操作，还是VPN架构，速度没有什么问题的。
------解决方案--------------------
如果是配送中心的DB，第二种方式后遗症会少一些。 数据库怎么都好说，关键是要确定业务流。我就是被客户那个多变的业务操作方式给折腾死的。
最近正为客户做套联锁仓库管理系统：所有的入库业务可以分为如下几类：采购入库，配送入库，调拨入库，加工入库，盘盈入库。当前有两种思路：1.对于入库操作只用两个表，trr_insert,和trr_insertdetail,在trr_inert中加入入库类型列：intype,来区别不同的入库方式。2,针对不同的入库类型，分别设计不同的表.如：trr_insert1和trr_insertdetail1，trr_insert2,和trr_insertdetail2，trr_insert3,和trr_insertdetail3。
以上两种方式，哪一种更合理？请指教！
------解决方案--------------------
各有各的好，
第一种方法所有数据都在一起，统计检索比较便捷适合各种各样的检索方式，适应当类型多种多样并且何以任意定制时；我就遇到所有仓库入库数据是存储在一起的，改动单号等非常麻烦，改动比较多；
第二种方法数据单独存储，检索效率比较高，检索上不太灵活，也许有时候需要视图来组合；适合每种类型存储类型固定，每种类型数据格式存储上变化比较大；如果不大还是不要分开；
个人认为多数人会采用第一种
------解决方案--------------------
1楼说的在理，如果各入库类型数据结构上没有差异的话，还是不要分开好了。你20家分店，每家分店都有不同的入库业务类型，这样分开入表，检索每个分店又得连多表
------解决方案--------------------
数据不是相当多，简单些好，不要分开好
------解决方案--------------------
我肯定要选第一个方法
------解决方案--------------------
用每一种方式，在统计查询方面比较方便的，而且20多台电脑操作一个表，没有什么问题的，我们做的时候，所有的单据（包括进仓、销售、调拨、盘点）都在同一个主表、从表的，30多台电脑同时操作，还是VPN架构，速度没有什么问题的。
------解决方案--------------------
如果是配送中心的DB，第二种方式后遗症会少一些。 数据库怎么都好说，关键是要确定业务流。我就是被客户那个多变的业务操作方式给折腾死的。