主页 / dba / 问题 / 229248
Accepted
Jason Whitish
Asked: 2019-02-09 08:15:06 +0800 CST

拥有更广泛的单表或基于业务流程的“子”表更好吗？

  • 772

我正在使用的示例是一个发票数据模型，在我们完成设计时可能会有大约 30 列。每行数据对于一张发票都是唯一的。

一些列被应用程序的多个部分使用（显然是发票编号、费用总额等），但也有一些列仅由单个进程使用。

例如，我们有三列反映varchar(18)我们应该跟踪的外部客户使用的控制编号 ( )，但只有跟踪过程会查看这些列。控制编号通常与发票一对一，因此每张发票只会有一个控制编号。还有一些发票没有控制编号，因为它们是从不跟踪控制编号的系统导入的旧发票（它们将占初始数据的大约 25%）。即使是那些较旧的发票最终也可能会获得一个控制编号（尽管它们很可能已经足够旧而不会发生）。

从数据建模的角度或性能的角度来看，采用这些列并为它们制作一个单独的表是否更有意义，或者，我们应该将它们留在 Invoices 表中吗？感谢这个特定示例的答案，但我也对更一般的答案感到好奇，因为我们肯定会再次遇到这种情况。

根据我阅读这篇维基百科文章的方式，我的意思是垂直分区，至少在逻辑意义上是这样（在这种情况下，两个不同的表将位于同一物理存储上）。

这是 OLTP 数据库的一部分。

大概 75% 的行最终会有一个控制编号。

sql-server database-design

1 个回答

  1. Best Answer

    我喜欢将真正具有不同目的的项目分开（假设这是一个 OLTP 系统，如 OP 所述）。

    请参阅我对以下 DBA.SE 问题的回答，该问题更详细地介绍了这一点，并提供了指向我关于同一主题的更多答案的链接，显示了实现此问题的各种示例：

    SQL Server 中的抽象类。他们甚至可能吗？

    一般的推理是这样的：

    1. 规范化为单独的表时，性能通常会更好。毕竟，我们是在“关系型”数据库管理系统中工作，对吧？是的，一些数据的消费者需要 JOIN，但每行数据更少 = 每个数据页更多行 = 每次读取加载到内存中的数据更多 = 更高效的 I/O 和内存使用。
    2. 规范化时可维护性更好。向团队的新成员解释数据来自相关表（明确表示为 PK -> FK 关系）比让他们记住哪些列属于哪些团队的所有古怪规则要容易得多/消费者。
    3. 如果/当业务规则发生变化时，调整数据模型并不困难。是的，事情总是会变的。但是，将相关表中的列移回主表（此处已简化）相当容易：
      1. ALTER主表到ADD新列
      2. UPDATE具有相关表中值的主表
      3. 调整/创建索引，如果新列应该被索引
      4. ALTER引用新位置的过程
      5. ALTER相关表到DROP列（可能需要事先删除使用该列的索引）
    • 4

相关问题