各位给个意见，哪种方案更靠谱？

[xugang96]

做的是进销存管理软件，涉及货物进出，每张单据标准结构都是：

主单据+明细单据（保存商品）；

现在问题是，是否需要新增一张 所有货物进出的明细表，这样便于后续查询统计，不需要用UNION 进行连接查询。

1.增加这张表的话，每次出库时都要新增记录；容易出错；但后续查询统计要快些；

2.不增加这张表的话，采取动态连接查询统计，出错概率低些，但数据量大时速度慢。

[發糞塗牆]

出入库可以是一个表，用标识列区分，也可以分开出库表和入库表

[xugang96]

引用 1 楼 yupeigu 的回复:

我觉得可以一开始就设置一个表，包含了进出，设置一个标志位flag：1表示进，0表示出

我说的这个表是各个单据交易时的那个明细记录

[阳泉酒家小当家]

引用 4 楼 xugang96 的回复:

[quote=引用 1 楼 yupeigu 的回复:] 我觉得可以一开始就设置一个表，包含了进出，设置一个标志位flag：1表示进，0表示出

我说的这个表是各个单据交易时的那个明细记录[/quote] 恩，你的意思是原来，你有多个单据，每个单据都有一张表，为了方便你不想汇总时，每次都union 。 这样的话，我觉得还是最好不要加表了，通过建立索引，过滤数据，可以加快查询的速度的，就算每次都要union

[xugang96]

销售单、销售商品明细 采购单、采购商品明细 销售退货单、销售退货商品明细 采购退货单、采购退货商品明细 入库单、入库商品明细 出库单、出库商品明细 调拨单、调拨出库商品明细、调拨入库商品明细 ......... 就是是否需要新增一张表来把交易审核后的明细记录下来（销售商品明细、采购商品明细、销售退货商品明细、采购退货商品明细、.......)

[發糞塗牆]

我觉得销售、采购这些可以何在一个表，对应的明细也合在一个表

[xugang96]

引用 5 楼 yupeigu 的回复:

[quote=引用 4 楼 xugang96 的回复:] [quote=引用 1 楼 yupeigu 的回复:] 我觉得可以一开始就设置一个表，包含了进出，设置一个标志位flag：1表示进，0表示出

我说的这个表是各个单据交易时的那个明细记录[/quote] 恩，你的意思是原来，你有多个单据，每个单据都有一张表，为了方便你不想汇总时，每次都union 。 这样的话，我觉得还是最好不要加表了，通过建立索引，过滤数据，可以加快查询的速度的，就算每次都要union[/quote] 销售单SELMain、销售商品明细SELSub 采购单PURMain、采购商品明细PURSub 销售退货单SLTMain、销售退货商品明细SELSub 采购退货单PRTMain、采购退货商品明细PRTSub 入库单SINMain、入库商品明细SINSub 出库单SOUMain、出库商品明细SOUSub 调拨单SDBMain、调拨出库商品明细SDBOSub、调拨入库商品明细SDBISub ......... 就是是否需要新增一张表来把交易审核后的明细(就是上面的SUB)汇总记录下来（销售商品明细、采购商品明细、销售退货商品明细、采购退货商品明细、.......) SubDet

[阳泉酒家小当家]

引用 6 楼 xugang96 的回复:

销售单、销售商品明细 采购单、采购商品明细 销售退货单、销售退货商品明细 采购退货单、采购退货商品明细 入库单、入库商品明细 出库单、出库商品明细 调拨单、调拨出库商品明细、调拨入库商品明细 ......... 就是是否需要新增一张表来把交易审核后的明细记录下来（销售商品明细、采购商品明细、销售退货商品明细、采购退货商品明细、.......)

就像你上面说的，是可以建立一张表，但是我觉得建了这个表，会导致业务逻辑更加复杂，容易出错。

[阳泉酒家小当家]

如果新建了表，因为你要修改数据，必须连着这个新建的表也一起 修改，就容易出错，而且需要修改原来已经稳定的程序，会增加工作量，还不需要测试。 如果性能更为重要，那么就新建一个表，修改相应的模块代码，只要测试通过后，就行了。 这个是一个折中的问题，2种方式，各有特点，关键在于你更倾向于哪种

[xugang96]

引用 7 楼 DBA_Huangzj 的回复:

我觉得销售、采购这些可以何在一个表，对应的明细也合在一个表

合在一起，数据量大了查询很慢，而且他们的字段还是有点区别的、更改业务流程时变更太大了

[發糞塗牆]

数据量大可以按照区域来做分区

[撸大湿]

数据量非常非常庞大时，单实例成为瓶颈时，可以按照区域来做分库 实例横向扩展，分布式事务由数据库上层控制 HA由中间层控制 失效的订单：比如退单、已提交不会被修改的订单等。移除sql server，转入分布式DB持久化，业务上支持读访问。其他正常业务不变

[發糞塗牆]

我上家公司也是做ERP的，最大的客户600多个店，单表记录也就4000多万而已，都还没达到要分区的地步。

[發糞塗牆]

Master 撸，求实例，理论的东西看不懂

引用 13 楼 tntzbzc 的回复:

数据量非常非常庞大时，单实例成为瓶颈时，可以按照区域来做分库 实例横向扩展，分布式事务由数据库上层控制 HA由中间层控制 失效的订单：比如退单、已提交不会被修改的订单等。移除sql server，转入分布式DB持久化，业务上支持读访问。其他正常业务不变

[xugang96]

看来倾向于 不新增那个明细记录表，采用动态链接查询统计了

[發糞塗牆]

连接的表过多时，比连接大表更加大开销

[xugang96]

引用 17 楼 DBA_Huangzj 的回复:

连接的表过多时，比连接大表更加大开销

那我写个存储过程、在客户请求查询的时候去读 单据的明细记录、把符合条件的记录存到临时表里，然后查询这个临时表。

[發糞塗牆]

那你要保证在写入临时表之前的查询速度可以

[xugang96]

引用 19 楼 DBA_Huangzj 的回复:

那你要保证在写入临时表之前的查询速度可以

去查询单个表，应该还行吧

[發糞塗牆]

优化过的话当然行，

引用 20 楼 xugang96 的回复:

[quote=引用 19 楼 DBA_Huangzj 的回复:] 那你要保证在写入临时表之前的查询速度可以

去查询单个表，应该还行吧[/quote]

[撸大湿]

引用 15 楼 DBA_Huangzj 的回复:

Master 撸，求实例，理论的东西看不懂

私聊。。。。