代码之家 › 专栏 › 技术社区 › Brann

规范化(sql视图)和性能/可流动性(sql表)之间的折衷是什么?

database-design sql

Brann · 技术社区 · 16 年前

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

最终重要的是这些最终的操作,尽管我必须记录导致它的所有事情。

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

即使有适当的索引,一个表也可能快得多(我的表最终将包含数百万个if项,并且应该可以在几乎所有列上完全搜索)
视图逻辑会很复杂,所以如果我想发展我的业务逻辑,恐怕几年后会使事情复杂化。

由于这两个原因,我有点想在业务流程结束时将数据写入表中,而不是依赖于视图,但是复制数据闻起来并不正确(而且这看起来有点像过早的优化,但是因为它是我设计中的一个中心点,所以我希望尽快解决问题)

你曾经面对过这样的选择吗?你决定了什么?

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

5 回复 | 直到 16 年前

Tom Smykowski 16 年前

我想你已经回答了你的问题,把它写下来。

这个问题可以用这样的方式来看待:一方面你有“实时数据”。你有新的数据,从中创建视图来显示“实时数据”也很不错。

但随着时间的推移,有更多的数据和逻辑变化。所以写下你前段时间的数据摘要是很好的。这是非常实用的-您不重复数据,因为您重新计算它们并保存到它们的新表摘要中。

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

更快的访问
可以有更复杂的逻辑
逻辑更改时保持存档数据不变

所以,当你满足这个(或部分)标准,而不是它的选择,你进入表格。

当我使用视图时,只显示其他新数据中的新数据。在非常非常简单的问题上。当事情变得更复杂时-你总是换到新的桌子上。

所以不要害怕去做。拥有一个访问速度更快的摘要表是一个非常不错的解决方案,它是数据库格式良好的标志。

注意这个表的设计—所以当业务逻辑发生变化时—您不需要改变这个表中的所有内容。然后一切都会好起来的!

MrTelly 16 年前

在这种情况下,我赞成新桌子。该视图有许多缺点—性能明显、复杂性和逻辑锁定。但是,过度架构的原因是,随着底层数据的更改,视图中的值也将更改。然而,在大多数情况下,这是一件好事,对于金融业务来说,对发生的事情有一个固定的记录不是更好吗?

Learning 16 年前

我总是决定更好的正常化。在您的情况下,尽管视图可能很复杂,但最好有新的表,而不是必须与所有数据更改操作保持同步。另外,视图始终是当前的,而您的工作日结束时的表填充每天只有几个小时是当前的。

此外,如果这个表中的数据由于任何原因而不同步,则会出现更大的问题。

Tom H zenazn 16 年前

正如mrtelly提到的,您确定您的最终结果表确实是视图数据的副本吗?或者,它实际上是作为视图数据中的项的结果而采取的最终操作的记录。

举个更清楚的例子,假设每次我的油箱空了一半,我就买10美元的汽油。我把这个写在日志上。有一天,我买了汽油,把它写在我的日志里,后来发现我的油压表坏了,我真的有3/4罐汽油。我现在应该从我的日志中删除10美元的购买,因为基础数据(在我的油箱里的汽油水平)已经改变了吗?好吧,也许那不是 更清晰的 例如,但希望它能让人明白这一点。记录结果与记录导致结果的事件不同。在金融应用中尤其如此。因此,我不知道您将最终结果存储在自己的表中会破坏规范化。

Denis Valeev 14 年前

甲 索引视图 就是这样。但是这种方法有很多限制,但是它通常是有利的,尽管如果实现不正确,它会有一些开销问题。使用这种方法,您不需要跟踪基表中发生的更改,数据将在索引视图中很好地积累起来。理论上。

参考文献:

Improving Performance with SQL Server 2005 Indexed Views
oracle:物化视图概念与体系结构