这些表设计中哪一个更能提高性能？

Question

我被要求创建一些东西来跟踪每天收取的帐户成本，我正在尝试找出一个支持这一点的数据库表模式。

这是我所知道的

• 公司拥有超过 250 万个账户
• 其中，他们目前平均每月工作 200,000 人（随着人员配备水平而变化，目前处于较低水平）
• 他们有 13 种不同的成本类型要跟踪，并且警告说将来可能会增加更多
• 他们希望每天跟踪成本
• 成本不会在整个库存中分摊。它们要么分布在每月工作的帐户数量 (200,000) 中，要么用户可以输入帐户标识符以将成本应用于一组帐户，或者他们可以简单地指定将成本应用于哪些帐户。

我的第一个想法是标准化数据库：

帐户ID
日期
成本类型 ID
数量

我的问题是，做数学。这张桌子很快就会变大。假设所有 13 种成本类型都应用于当月的所有工作帐户，即每月200k * 13 * N days in month大约 75-8000 万条记录，或接近每年 10 亿条记录。

我的第二个想法是对其进行非规范化

帐户ID
日期
总消耗
成本类型 1
成本类型2
成本类型 3
成本类型 4
成本类型5
成本类型 6
成本类型7
成本类型8
成本类型9
成本类型10
成本类型11
成本类型12
成本类型13

这种方法更加非规范化，每月最多可创建 600 万条记录 ( 200k * N days in month)，或每年约 7200万条。它比第一种方法少很多，但是如果公司将来决定使用新的成本类型，则需要添加另一个数据库列。

在这两种方法中，您更喜欢哪种方法？为什么？您是否可以想到另一种替代方法可以更好地处理此问题？

我对报告绩效最感兴趣，包括总结报告和详细报告。将成本分摊到帐户的工作将在无人在场的情况下每晚运行。次要问题是数据库大小。现有的数据库已经接近300GB，我相信磁盘空间在500GB左右。

数据库是 SQL Server 2005

Answer 1

一年 10 亿条记录并不多。

通过分区（可能是每个 Costtype）和归档，它是可以管理的。

要存储的数据项数仍然是200k * 13 * N。作为列，每页的行数会更少，并且比行占用更多的空间。如果“CostType1”不是固定长度的数据类型，您可能会受益，但它是微不足道的。

正如他们所说的“亲吻”

Answer 2

虽然您的设计肯定可以带来白天或黑夜的不同，但在这种情况下，我将更多地关注索引，包括根据需要覆盖索引。我还将研究 SQL Server 为您提供的一些用于处理非常大的表的工具，例如表分区。

这样想一下，即使表中有 800 亿条记录，通过适当的索引，您在任何给定点真正感兴趣的记录将在磁盘上物理分组在一起。由于 SQL Server 中数据的组织方式，按索引边界拆分的数据也可能在另一个表中，因为它不必读取整个表来获取所需的内容。

如果您还选择对表进行分区，则可以提高访问时间和插入时间。