预先计算的SQL属性指南

Question

我经常会处理具有从其组成或子成员派生的属性的聚合或父实体。 例如：

• 的byte_count和packet_count一个的TcpConnection对象从它的两个组成的相同的属性计算TcpStream对象，而这又是从它们的组成计算TcpPacket对象。

• 一个Invoices对象的total可能基本上是其组成InvoiceLineItems价格的SUM（），并InvoiceLineItems了一些运费，折扣和税收逻辑。

当处理数百万个数据包或数百万个已开票的订单项时（我希望！），按需计算这些派生属性的速度（无论是在VIEW中还是在报表或Web界面等表示逻辑中更常见）通常会令人无法接受。

在性能问题迫使您动手之前，您如何决定是否将衍生属性“提升”到预先计算的字段？

Answer 1

在性能折衷迫使我动手之前，我个人不会取消规范化（因为规范化的缺点太严重了，恕我直言），但是您可能还会考虑：

1. 便利性 ：例如，如果两个不同的客户端应用程序要计算相同的派生属性，则它们都必须对查询进行编码以计算它们。 非规范化以一种更简单的方式为两个客户端应用程序提供了派生属性。
2. 随时间推移的稳定性 ：例如，如果用于计算派生属性的公式是可变的，则非规范化可以让您在某个时间点捕获和存储派生值，因此以后的计算将永远不会出错
3. 更简单的查询 ：增加数据库结构的复杂性可能意味着您的Select查询在客户端更简单。
4. 性能 ：选择对非规范化数据的查询可以更快。

参考： 数据库程序员：关于非规范化的争论 。 一定要阅读他的文章， 保持正确的非规范化值正确 -他的建议是使用触发器。 这就带来了需要权衡的非规范化。

Answer 2

基本上，您不需要。 您对性能的担心会迫使您动手。

这是最好的答案，因为99％的时间，你不应该预先优化这样的，最好是刚calc下它的飞行。

但是，客户端应用程序开发人员带着错误的先入之见来到服务器端是很普遍的，例如“ 按需计算...派生属性...- 常常慢得令人无法接受 ”，这是不正确的。 。 此处正确的措词是“ 很少会令人无法接受地缓慢 ”。

因此，除非您是此方面的专家（DB开发架构师等），否则您不应该从事过早的优化。 等到很明显 ，就是已经被固定， 再看看前聚集。

Answer 3

数据必须是最新的，这实际上决定了如何实现它。

我将假设2个简单状态：当前或不当前。

• 当前：索引视图，触发器，存储的proc以维护聚合表等
• 当前不是：Reporting Service快照，日志传送/复制，数据仓库等

就是说，我将使用与生产相同数量的数据进行开发，因此我对响应时间充满信心。 您应该很少对代码性能感到惊讶...