我有一个包含存款表( margin 、宠物存款等)的数据库，在某些情况下需要减少这些存款，即有人购买了补充保险。我是否应该有一个名为 alter_deposits 的表，其中将包含减少的条件以及金额，或者这是否属于应用程序代码中的业务逻辑？
提前致谢!
最佳答案
在这种情况下，我喜欢尝试将规则概括为尽可能基本的规则。所以你可能有一个减少 x% 的统一减少规则。然后你可能有一个基于条件的规则，所以你可以说当余额大于 y 时减去 x%。
在您对规则进行概括后，我将以通用形式在业务逻辑中实现规则，并且在您的数据库中您可以存储当前事件的规则类型及其输入。
而且您可以在不安排停机时间的情况下执行此操作，放入新规则，应该像更新数据库一样简单，如果有新规则类型，您只需部署新代码即可。当然这取决于您的环境，我知道在 .net 中这应该很简单。
我在一个非常有趣的基于规则的处理系统上工作，我们基本上构建了一个 And & Or 操作数的二叉树，其运算符将返回 true 或 false，如果树返回 true，我们就执行操作。这都被序列化为 Xml，这让存储机制与规则类型及其数据要求无关。
编辑
基于规则的系统可以非常强大。我用它们来帮助定位分布在数千个不同库存中的小部件，并根据任意数量的标准对购买小部件的最佳地点进行排名。我看到他们过去常常在零件上进行征服，例如在汽车领域，OEM 喜欢在 AM 零件上竞争，但仅限于某些情况。
您可能已经定义了规则的超集，并且当项目沿着链向下传递时，您可能会发现其他规则。规则可以由表达式和操作组成。该表达式可以表示为子条件树，当它为真时，您的操作将评估为真或假。
如果您使用 .net，您实际上可以使用表达式树构建一个相当动态的系统，并动态创建可以表示操作数和 Action 的 lamba。
有一些预建的规则引擎可以帮助快速启动事物，但我从来没有找到一个足够便宜或足够基本的来满足我的需求。
在我看来，这个概念的一个扩展是工作流编程。因此，当存款进入时，假设在您的规则运行后存款结果 > 25%。在这种情况下，您需要一名员工来批准这种情况。工作流引擎可以封装这种类型的逻辑，并以比传统编码更流畅的方式表达它。但是所有的事情都有很多缺点。每次我开始使用工作流引擎时，它最终都会因为各种原因而被毁掉，但通常是因为我们的工作流太简单，无法证明学习引擎的成本是合理的。
关于database - 这属于数据库还是代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1203552/