sql - 规范化(SQL View )和性能/可行性(SQL 表)之间的权衡在哪里

Question

我有一个相当长的业务流程，最终会导致财务运作。

最终重要的是这些最终操作，尽管我必须记录导致它的所有内容。

由于最终操作中包含的所有信息都可以在其他表中获得(在业务过程中使用)，因此使用 View 是有意义的，但 View 逻辑会相当复杂(涉及数十个表)，我担心:

1. 即使有适当的索引，表也可能会更快(我的表最终将包含数百万个项目，并且应该可以在几乎所有列上完全搜索)

2. View 逻辑会很复杂，所以如果我想发展我的业务逻辑，恐怕几年后事情会变得复杂。

由于这两个原因，我有点想在业务流程结束时将数据写入表中，而不是依赖于 View ，但复制数据的味道不太对(而且看起来也不错有点像过早优化，但由于它是我设计的中心点，我想尽快解决这个问题)

你有没有面临过这样的选择？你决定了什么？

编辑:创建一个表显然会导致我的情况重复，即。写入表中的数据存在于数据库中的其他地方，并且可以仅使用连接而不进行任何计算来检索。

Answer 1

我想你已经回答了你的问题，把它写在 Brann 上。

这个问题可以这样看:一方面你有“实时数据”。你有新的数据，从它们创建 View 来显示“实时数据”也很好。

但是随着时间的推移，数据和逻辑的变化越来越多。因此，最好记下一段时间前的数据摘要。这非常实用 - 您不会重复数据，因为您会重新计算它们并保存到它们的新表摘要中。

所以当你这样想的时候，很明显在这个例子中新表会更好。当你写的时候:

• 访问速度更快
• 可以有更复杂的逻辑
• 逻辑改变时归档数据不变

因此，当您按照您的要求满足此(或部分)标准时，而不是选择 - 您进入表格。

只有在从其他新数据中显示新数据时，我才会使用 View 。在非常非常简单的问题中。当它变得更复杂时 - 您总是会切换到新表。

所以不要害怕进入它。拥有一个访问速度更快的汇总表是非常好的解决方案，它是数据库结构良好的标志。

请注意此表的设计 - 因此当业务逻辑发生变化时 - 您无需从一开始就更改此表中的所有内容。然后一切都会好起来的!