问使用多个联接派生值是个好主意吗？

EN

如果规范规定您应该存储最终成本，那么您应该存储最终成本(即使这不是正常形式)，但它并没有说明在存储之前如何计算该成本。

如果您建议每次查看时计算价格，则需要仔细考虑基本数据是否会随着时间的推移而改变。如果一个产品可以改变价格，你需要对价格进行一次全面的审计，这样你就可以在得出总价格时找到合适的价格。如果您已经在维护这样的审计，那么这是“免费的”，但如果不是，这可能是大量的额外工作，以节省存储在销售点的衍生价值。当然，如果您可以在订单和产品之间添加一个额外的实体，存储在特定销售中为该特定产品支付的价格，这意味着您可以很容易地实施临时的“经理特别”S或一次性折扣等临时价格变动。

要回答标题中的直接问题:只要存在适当的索引结构，就可以找到一个具有多个联接的值，以提高此过程的效率。无论您是在数据库中还是在应用程序的另一层中最好地这样做，都会引起很多争论，并且取决于您的总体设计哲学和效率(遵循设计哲学是一致的，除非这会对效率产生重大影响(不过在这个时候，它也会对哲学产生疑问，而不是绕开它一次)。对于一个低负载的用例来说，让数据库完成工作可能更有效，因为这是SQL作为查询语言创建的对象的排序，而DB有其指尖的所有信息。如果要在更大的范围内工作，那么将逻辑推到外层可能更好，因为(在DB服务器加上web服务器的例子中)，比数据库端更容易扩展web服务器( web远程相对容易创建)(在数据库端有一系列新的问题，比如您是否需要主/主复制或其他许多选项之一，以及您选择了哪个选项，以确保每个节点在任何给定的时间内保持同步，以及在所有DB节点上确保事务的完全一致性，这是“一致的”，等等)。由于DB端的扩展可能很复杂，因此有充分的理由将尽可能多的逻辑推入外部层，并让DB只负责数据存储/恢复和核心约束管理(这也使得将来需要时可以更容易地在DB平台之间迁移)。

关于触发器，请考虑它们的灵活性，因为它们可能更难调试，因为它们本质上是在代码背后发生的事情。他们有自己的位置，你需要决定你的项目是否是其中之一。用于保存的存储过程是另一种选择，将逻辑移动到应用程序的另一层也是如此。

你的讲师故意对你的问题含糊其辞，我努力不给出任何直截了当的答案，而是列出了一些“要考虑的事情”(可能还有更多的“需要考虑的事情”，请考虑一下)，因为他/她希望你自己做出一个设计决定，以证明你对一般领域的理解，而不仅仅是遵循特定指令的能力。不要太担心，只要你能为你所做的选择提供一些理由--在一次学术考试中，如果你能以某种方式证明你所做的选择和你拒绝的任何选择，你会因为给出一个不太理想的解决方案而获得分数。要小心地陈述你所做的假设和你认为但与此实现无关的因素--如果你的假设是错误的，那么你仍然可以在那些不确定的假设的基础上做出合理的选择，如果你因为错误的假设而做出错误的选择(如果假设是正确的，那就好了)，不要记录那些假设--你不会得到一半的信用，因为标记无法说明你为什么做出选择(糟糕的输入假设或简单的坏想法)。

有些讲师有足够的线索来浏览这样的网站，看看人们是否对他们的作业提出了问题。不要被诱惑从这里得到一个答案，你可以只是copy+paste，因为你会得到零分(或更糟！)如果你注意到了，那就是你所做的。