一点想法，正在尝试，顺便提出来，抛砖引玉，欢迎各位走过路过的大神提点意见。
先解释我为什么有这个想法：举例说库存管理，直觉来讲，我们会创建一个库存表，以新建、修改库存产品的信息，然后同时会有部分数据如当前库存、已入库总数、已出库总数、末次入库时间、末次出库时间等等相关的、来自于入库表、出库表填报过来的随时变动的数据——这部分随时变动的数据在修改库存表时是不应当被变动的，那么，现在出现一个场景：


1、员工甲需要修改调整库存产品A名称规格，进入了库存表选了产品A，进入了修改状态；
2、员工乙需要入库产品A，在员工甲修改时创建了入库单并进行了入库N只的操作；
3、在员工甲仍在修改状态下，数据库中的产品A库存数已发生了改变；
4、员工甲保存了修改结果，使数据库中的产品A库存数又变成了他刚进入修改状态时，员工乙入库前的数字。


然后，重点是解决方法：
1、创建系统时将信息与变动数据分开两个表保存，信息表在每次打开时重新读取相关数据，这个对全新的系统应当是建议的方案，对于初学时不理解这个窍门时就创建好并投入使用的老系统，更改起来就比较费工夫；
2、就是我现在想的一个办法，可行性现在正在研究：还是如上面案例中那样，信息与数据混在一个表中，但是在每次保存时，在表间公式中先将不应同时变更的数据读取出来，而将常规的保存动作放在这条表间公式之后。

各位觉得可行吗？可能会有什么弊端？

这个是设计问题，非软件功能问题。
首先最大的问题是库存可以人为直接修改，这个是致命的，如果是盘点，理应盘点单操作更新数据，做到有迹可寻（题外话）
同理，作为产品，当入库前，就应该整理好基础数据，并且产品是根据产品编号对应的，而不是名字和规格，这个可变和多变的，不应该作为入库判断的标准

hong90342 发表于 2019-11-19 13:33
这个是设计问题，非软件功能问题。
首先最大的问题是库存可以人为直接修改，这个是致命的，如果是盘点，理 ...

谢谢参与。

首先，这就是个设计问题。

其次，库存信息只是个例子，入库出库盘点肯定是另外有表进行操作，并且是匹配全局唯一的存货编码进行读写，如果库存信息量比较大，不想另外再做一个“库存信息修改”表呢？是不是可以用我想的这个笨办法来避免数据覆盖？

——当然，我开这个贴子，目的不是这个，而是说如果使用覆盖前读数据库来避免不适当的覆盖，这种方法有什么弊端？

我上面的意思是，不想发生你说的情况，就是不要直接操作存货信息模板，必须另建一个更新表，做到有迹可循

至于你说的表间公式执行前，判断模板情况根本不是一回事，1个是A模板的信息录入和修改， 1个是B模板的表间公式执行时机。你要如何让计算机识别A模板数据正在修改，并且是当前回写更新的目标数据，是否执行，不执行，使用B模板则发现入库不准呢，不是自相矛盾吗？ 所以有这功夫，不如想下如何规范系统使用规则和人为管理

PS：复制一个模板修改成批量修改，并不比上面的思路来得复杂，不管哪种形式，数据的更新，均以执行时机先后为准

hong90342 发表于 2019-11-19 14:15
我上面的意思是，不想发生你说的情况，就是不要直接操作存货信息模板，必须另建一个更新表，做到有迹可循
...

谢谢建议。
分表分工、留痕、专业化的确是大家都应当前行的方向。
我也只是对一个老系统的问题进行简易调整有了点想法，提出来探讨一下。

做个库存表的视图，保存时重新提取一次当前库存数据也可以解决，但不适用于大量并发操作用户操作相同产品，如果库存移动频繁数据采集点多，就要加很多的判断逻辑，估计得用专门的仓库管理软件。

楼上说得有道理。用这个系统的就是个小厂，三个五个人的办公系统，管管库存量，出入库打个货单，就这样用用。
老系统了，不想大改。

下午测试了，这个方案是可以用的——但同意楼上ST5612朋友讲的，估计不适用于大量并发操作的环境。

正经写系统还是应当遵守上面那位梁工说的方案，也是我在主贴中说的解决方案1号。

这个是设计问题，非软件功能问题。
首先最大的问题是库存可以人为直接修改，这个是致命的，如果是盘点，理应盘点单操作更新数据，做到有迹可寻（题外话）
同理，作为产品，当入库前，就应该整理好基础数据，并且产品是根据产品编号对应的，而不是名字和规格，这个可变和多变的，不应该作为入库判断的标准

hong90342 发表于 2019-11-19 13:33
这个是设计问题，非软件功能问题。
首先最大的问题是库存可以人为直接修改，这个是致命的，如果是盘点，理 ...

谢谢参与。

首先，这就是个设计问题。

其次，库存信息只是个例子，入库出库盘点肯定是另外有表进行操作，并且是匹配全局唯一的存货编码进行读写，如果库存信息量比较大，不想另外再做一个“库存信息修改”表呢？是不是可以用我想的这个笨办法来避免数据覆盖？

——当然，我开这个贴子，目的不是这个，而是说如果使用覆盖前读数据库来避免不适当的覆盖，这种方法有什么弊端？

我上面的意思是，不想发生你说的情况，就是不要直接操作存货信息模板，必须另建一个更新表，做到有迹可循

至于你说的表间公式执行前，判断模板情况根本不是一回事，1个是A模板的信息录入和修改， 1个是B模板的表间公式执行时机。你要如何让计算机识别A模板数据正在修改，并且是当前回写更新的目标数据，是否执行，不执行，使用B模板则发现入库不准呢，不是自相矛盾吗？ 所以有这功夫，不如想下如何规范系统使用规则和人为管理

PS：复制一个模板修改成批量修改，并不比上面的思路来得复杂，不管哪种形式，数据的更新，均以执行时机先后为准

hong90342 发表于 2019-11-19 14:15
我上面的意思是，不想发生你说的情况，就是不要直接操作存货信息模板，必须另建一个更新表，做到有迹可循
...

谢谢建议。
分表分工、留痕、专业化的确是大家都应当前行的方向。
我也只是对一个老系统的问题进行简易调整有了点想法，提出来探讨一下。

做个库存表的视图，保存时重新提取一次当前库存数据也可以解决，但不适用于大量并发操作用户操作相同产品，如果库存移动频繁数据采集点多，就要加很多的判断逻辑，估计得用专门的仓库管理软件。

楼上说得有道理。用这个系统的就是个小厂，三个五个人的办公系统，管管库存量，出入库打个货单，就这样用用。
老系统了，不想大改。

下午测试了，这个方案是可以用的——但同意楼上ST5612朋友讲的，估计不适用于大量并发操作的环境。

正经写系统还是应当遵守上面那位梁工说的方案，也是我在主贴中说的解决方案1号。