不清楚你的逻辑,你可以处理数据都在后台数据表啊,最后一次性把数据加载显示出来即可----这个就象前面的示例。
比如说我想在办理入库的时候,已知它们的初始计划数量A,但同时想知道各种物资截止目前为止的调整数量B(它来源于tbAlterD),同时想知道它截止上次入库为止已经入库的数量C(它来源于TbRKD表),这样才能办理入库(因为要求入库的数量不能超计划,也就是本次入库的数量必须不能大于A+B-C)
象你所说的在后台数据表,是说全局代码表,还是后台的数据库实体表呢?
如果是全局代码表还好一点,要是数据库实体表要实时保存B和C,涉及到多人同时操作时,可能会有不可预知的麻烦,比如说数据同步计算错误,甚至会不会导致数据库死锁。
基于这种考虑,我才想着在客户端动态计算B和C值,虽然也有可能导致多人同时操作时会有违背这个业务规则的数据发生,但可以有数据统计功能向用户提示这种非法数据。这样也免去了频繁更新后台数据的情况。冗余有一定的好处,但这种情况下冗余的设计可能并不是个好方案
至于赋值的数据冲突,应当不会有太大的问题。因为B列和C列的数据来源于不同的表,而且全局代码表设了两个,分别来做B和C所需的值的计算,在统计和赋值上应当不会有冲突。
其实,我也想过用一个全局代码表X,让它执行SQL,合并B和C的统计,这个SQL比较复杂了,什么left join之类的嵌套一堆看得我眼晕,然后界面表的源就直接设为X,然后加载,但实际效率不理想,因为数据量太大了,本身SQL执行的速度就不快。
后来考虑了一种方案,就是把物资按它们所属的分类整成树,点击树节点的时候,就只加载这个节点(以及它的所有子节点)的物资,这样,计算量会明显小很多。比如说物资分为10类,就算每一类有4000种,也比一次性计算和加载4万行要快得多。
本来按我的想法,物资明细搞个两三千行就已经很大了,没想到用户搞出来的明细数量将近10万行(我一看就几乎晕倒),想让用户搞简化一点,用户不接受,没办法,只能照办
[此贴子已经被作者于2019/3/13 21:43:14编辑过]