我们有一个与销售相关的项目。数据库设计？
现在我们将产品的库存保存在一个名为Stock的单独表格中。在销售，销售退货，采购和退货时，库存表将被更新。它运作良好，但在我们删除或修改销售或采购之一时，维护库存更加困难。
我告诉我的老板，我们不想把股票保存在一个单独的表格中，而是写一个函数来计算相关表格中的股票（sales,purchase，...）。每当用户想知道股票时，他们都会很容易地调用该函数来获取股票。因此我们不需要考虑库存维护。我认为它是一个好主意。
但他告诉我，如果有很多记录会来，这个函数将需要更多的时间来执行，并且会降低软件的效率。我不知道这是否正确。我知道的一件事是它反对DB的规范化。我们不需要将计算的值保留在表格中或表格外部。
我怎么设计这个数据库？是不是单独的Stock表更好？
关于该主题here，由艾伦布朗提供了一个很好的研究。
一般来说，最好有一个规范化的数据库。如果你有数据重复，而且有一天软件不能正常工作，那么你最终可能会得到不一致的数据，这对任何人都没有好处。
对于大多数用途而言，您可以根据您的建议使计算足够高效，以便您可以对原始数据执行计算。如果这对您的特定项目的可伸缩性确实存在问题，那么可能最好有一个包含计算值的表格。这绝不会被视为原始数据，并且可以在任何时候重新计算。那么你的数据是安全的，并且你的计算速度很快。
另一种方法是根据你的DBMS来考虑一个视图。
您的库存表的内容是什么？你是否有不同的库存可以放置同一种产品？如果只有一只股票，我会建议单独的表格或计算的股票。计算库存可能非常复杂且耗时，尤其是如果您的查询比查询更频繁。然后，您应该将库存量作为产品表的一部分。
一般而言，您希望更多的规范化来保持数据完整性，并且这也趋向于针对数据更新进行优化（您不需要在多个位置更新同一条信息）。唯一的例外是如果您的数据库将主要用于报告，并且只是偶尔更新。然后，由于您在报告时不需要从许多不同地点获取信息，因此在几个不同的地方进行更新的成本（因为您是非规范化的）会得到报酬。
如果您的数据库必须快速进行交易（更新），并且只是偶尔进行报告，则尽可能标准化。以这种方式保持所有数据的一致性也更容易。但是，如果你只是偶尔更新，而且主要是报告（即阅读，或只是将数据从数据库中提取出来），那么你的老板可能是对的，这可能是一个更好的选择。但是，处理错误条件和保持数据完整性会更复杂（您必须更多地考虑什么是“逻辑事务”，以及什么时候出现错误时何时退出到目前为止所做的所有更新）。
你有没有想过使用触发器来更新库存表？
在一个完美的世界里，所有变化的总和等于当前的库存物品数量。在现实世界中，变化的总和更多的是对库存物品数量的统计预测。如果你想让现实世界变得完美，你必须考虑到这个数字中所有可能的变化。因此，除了购买和销售之外，您还需要初始库存的交易类型，盗窃，自然灾害，捐赠给红十字会等。如果预测变量和实际项目数量出现一些不可预见的情况，您需要虚拟交易来纠正计数原因。所有这些都会干扰你的交易表。
你老板的表现论证也是有效的。每次您需要库存物品的数量时，您必须汇总所有交易。如果你有很多这样的数据库，那么即使你正确地为事务处理表建立索引，你也可以从索引中获得总和，这可能会成为性能瓶颈。
并不完全同意库存表违反正常化。您现在有库存的物品数量以及购买或出售的物品数量在概念上并不相同，它们是不同的数字，这些数字恰好与您的业务采购和出售它们的业务规则相关联（而不是比制造并捐赠给红十字会），并且如上所述，它们只在完美的世界中完全相关。