计算字段与数据库中的复杂查询（使用JPA）

Question

我们有一个库存控制系统，用于管理进出业务或指定地点的某些物品的流量。我们在数据库中有记录，表示库存的移动以及入库和出库交货。

如果您要将所有入库交货和外向交货相加，并从另一个中减去一个，则您拥有当前库存水平。要查找给定位置的当前数量，您还必须包括移动记录。

这显然会导致一些非常复杂的查询只是为了获得当前的库存水平。更糟糕的是，我们使用的JPA无法在QL中处理所有这些，因此我们最终不得不使用本机查询或查询大型结果集并在应用程序中处理结果。

显然，添加数量字段会使生活变得更加轻松，但在技术上是多余的，并且必须针对每次库存变动进行更新。

你会采用哪种方式？

Answer 1

我假设您已经对数据库结构进行了相当规范化，因此您没有冗余列，因此质疑是否需要将看似冗余的数据添加回设计中。

我倾向于添加数量列提供，您可以确保每当本地库存水平发生变化时，列中的数据可以保持一致，无论是数据库中的触发器还是其他代码在您的应用程序中处理此问题。详细说明确保一致性所需的工作，如果它的影响仍然低于运行您正在考虑作为替代方案的潜在大型查询，并且您可以通过类似的努力来实现它们（并且可能获得性能优势，好吧），我很想添加列和必要的代码以确保其一致性。

我在这里可以看到的危险（这就是为什么我说我倾向于添加专栏并且没有说“耐克”）是确保数据一致性所需的努力可能比人们想象的要高三个月之后，你最终会得到一个半生不熟的实施和数据一致性问题。

Answer 2

要考虑的几个想法：

拥有StockLevel实体？

显然，我不知道您当前的域模型/表格是什么样的，但也许您可以拥有StockLevel实体：

// annotations not shown
public class StockLevel {
    private Item item;  // unidirectional one-to-one?
    private int inbound;
    private int outbound;
    public int getInbound ...
    public int getOutbound ...
    public int getLevel ... // derived from other two
    // setters
}

您需要确保StockLevel实体始终在与库存变动相同的交易中更新吗？然而，这些StockLevel可能成为争论的来源。

使用特定于DB的解决方案

您可以考虑使用数据库触发器来防止需要不断重新计算相同的数字。

您还可以使用存储过程隐藏数据库如何计算其来电者的库存水平。因此，您可以开始将查询移动到SP中，然后在保持相同应用程序代码的同时调查其他方法。

Answer 3

这是计算列的一个很好的候选者。您可以获得数量列的好处，而无需担心必须与其他字段保持同步。