我负责创建用于记录生产数据的数据库。（我没有正式的数据库或SQL经验）使用Microsoft SQL
我可以想出两种不同的方式来构建我们记录的数据 1：我可以记录每种材料的累加器的当前值 2：我可以记录上次记录产生的金额。
在某些背景下，我们将每分钟记录一次信息，以跟踪混合中使用的每种材料的产量和数量。
我们有报告显示，在一天的时间内，某一天内会产生多少材料和混合物。
我想我的问题归结为在查询中对值求和或搜索与材质/混合相关的最大值更快？
答案 0 :(得分：0)
如果记录包含净数量，在任何给定时间点找到数量肯定会更快。然后，当您想要查找数量时，您只需阅读一条记录 - 最新记录或适当日期和时间的记录 - 然后选择数量。如果您存储了增量，则必须从第0天开始对它们进行求和。
另一方面，如果存在多个独立的变更源，和/或如果可以取消或撤消更改，则存储“当前金额”成为问题。如果交易无序到达，或者旧的交易被修改或删除，会发生什么？
这方面的典型例子是银行账户余额。存款和取款可能在不可预测的时间来自多个来源。我们经常想要不按顺序发布交易。较旧的交易可能会被取消。
例如：
1月1日：账户以1,000美元开盘。余额= $ 1,000。
1月2日：存款300美元。余额= 1300美元。
1月3日：提取200美元。余额= 1100美元。
1月4日：检查用于1月2日存款反弹。反向存款。所以1月2日的余额改为1000美元。但是1月3日的余额呢？我们必须将其更新为800美元。
在现实生活中，可能会在退回支票后发生一系列交易。如果我们将最终余额存储在每条记录中，那么每条记录都必须更新。
交易的生效日期通常与输入系统的日期不同。因此，我们将经常发现必须在现有事务之前在事务中插入事务，然后必须更新所有后续事务。
现在也许你的柠檬水摊是一种不同的过程。如果我们在碗里加水，我们可能会说，“加入足够的水使其达到'完整'标记”而不是“加4升”。如果是这种情况 - 如果在大多数情况下用户知道并进入计算机的是新的总数量而不是增量 - 那么你输入的是总数量是否合理，如果你关心的话三角洲，你计算它。但是如果用户知道的是delta，那么他们应该输入delta，你应该携带delta，并计算数量。
是的，存在的问题是，如果您存储的全部是增量，那么计算净数量需要从第0天开始累计所有记录。如果记录数量适中，这可能是完全可以接受的。如果没有，我有时会做的事情是将“总记录”与某个日期的运行总数保持一致。然后，为了获得当前数量，我找到最新的总记录，然后添加自该日期以来的交易金额。编码会带来额外的痛苦，但会大大提高性能。