设计进销存数据库时如何实现库存预留

[henreash]

做一个进销存系统的时候，要求库存量可以预留。发货的时候减少预留

有如下实现方式
1、给订单写触发器去增加库存预留量 给发货单写触发器减少库存预留量
2、做添加订单的存储过程，同时完成订单添加和增加预留量
做添加发货单的存储过程，同事完成发货单添加和减少预留量
3、在程序中完成

问题：
1、上面3个方法各有什么优缺点？还有没有其他的方法？
2、要保证预留量精确（订单数量和预留量一致）应该采用什么机制？
3、我看微软的一个数据库设计也使用了触发器，但是他不是简单的去修改预留量
而是每次触发都是重新汇总预留量（预留量=Sum（订单数量）-Sum（发货数量））。
这里为什么不去简单的去增加减少预留量呢？每次都去汇总一下肯定精确，但是效率问题呢？

[qiyousyc]

还是用第2重方法好些。

[henreash]

顶起来

[大宇_]

应该考虑到并发问题，和进货出货同时发生
应该是预留量=Sum（订单数量）-Sum（发货数量)

[tim_spac]

基本论据：
A: 数据表分为四类：基本信息表、字典表、交易表、统计表，这里涉及到的是后两种；
B: 交易数据经常被增加，统计数据时常被更新；交易数据数据量会比较大，统计数据量相应少一些；交易数据的查询相对较少，统计数据的查询相对较多；
C: 没有哪一种方式是绝对好的，要视具体的应用环境而言；


三种方式（a:触发器,b:存储过程,c:前台应用）相比：
a:基本能够保障在任何状态下的记录增加均更新统计数据，对数据完整性有良好的保障；表间耦合紧密；
b:也可以完成更新统计数据，但不能直接对交易数据库进行更新（否则会影响数据的完备性）；
c:必须在前台应用中完成交易数据的登记，否则会影响统计数据的正确性；表耦合度最小；

关于微软样例的方式：
一个应用系统最重要的是正确性；能够快速响应但响应的不是正确结果是无意义的。

[kelph]

3楼说的不错

lz还要注意单据的反向操作

[henreash]

谢谢大家 预留量=Sum（订单数量）-Sum（发货数量) 这个肯定没有问题 应该采用这种保险的方式。
但是那种简单的加减预留量方式不能保证数据一致吗？是不是只要保证并发控制就能一致呢？

[fuda_1985]

mark

[tim_spac]

可以考虑采取一种中庸之道：
1: 每日交易量少的时候对统计表进行核准计算：“预留量=Sum（订单数量）-Sum（发货数量)”；
2: 日常的交易更新按统计表加减数的方式更新；

[wzy_love_sly]

学习

[JiangHongTao]

进销存软件一般遵循日清月结制度。
每日的交易只要加加减减就行了，触发器也好、存储过程也好、前台也好只要按照业务规则就行。
每月做好月结，月结说白了就是算平衡，核对你的日常业务数据是不是存在差错。
如果你的程序没有BUG的话，月结的数据是一定能够平衡的，如果出现了不平衡，首先是要调帐（非正常业务）
然后是要修正程序BUG了。

个人认为对于较为复杂的业务处理比较理想的做法是放在存储过程中（借用OO的思路）
触发器过于死板，而且有很多功能限制。
前台，呵呵，各种因素太多，一般不太可靠。

[fengf840621]

对于库存的处理，应该与进货和发货一起处理，如果有货到了就要入库，此时应对库存中的数量进行增加，当有货出库时就应该相应减少！

[hui_hui_2007]

关注一下。