sql - 数据库表分析混淆

Question

我正在使用sql-server-2008-R2. 我有一个表，其中包含三种类型的数据，并且这些类型在另一个表中。

T = 表，F = 字段，FK = 外键，PK = 主键

T1: F1(PK), F2(TypeID), F3, F4, F5, F6, F7

T2: F1(TypeID, PK), F2(TypeName)

我想添加第四种类型，但这种类型有一个附加属性（例如 TypeRate）。
在项目开始的第一周，我的 T1 表将至少有 300 万条记录，然后它会减慢到每月大约 300 万条记录。

现在我想知道下面列出的方法中哪种方法最好：

A. 向主表 (T1) 添加一个字段：

T1: F1(PK), F2(TypeID), F3, F4, F5, F6, F7, F8(TypeRate)

F8 大多数时候为空（对于其他类型的记录），但我只有一张表

B. 添加另一个表，其中包含 T1 具有的所有字段 (T3)：

T3: F1(PK), F2(TypeID), F3, F4, F5, F6, F7, F8

这样 T1 大部分时间都没有空值，但我将有两个大部分相似的表。

C. 添加描述表（T4）：

T4: F1(PK), F2(FK:T1.PK), F3(TypeRate)

这样我的 T1 表就没有空值，并且对于第四种类型的记录，附加数据在 T4 中（描述表）

score 1 · Accepted Answer

如果不描述您要完成的工作，您就不能要求“最佳”解决方案。好吧，我想你可以问，但这使问题无法回答。

如果您试图最小化空间（内存和磁盘空间），那么将表一分为二——正如选项 (b) 所暗示的那样——将是最小空间解决方案。但是，您选择此选项的可能性非常非常小。空间效率的增益是最小的，将一个实体分成两个表通常不是最好的解决方案。

对于每个 NULL，第一个解决方案在每行中都会产生一些额外的开销——一个非常微不足道的空间量。在许多情况下，这似乎是一个很好的解决方案。无需额外连接即可使用数据。

第三种解决方案也很好。它需要一个额外的连接来获取数据。但是，如果引用表很小或者您在键上构建索引，那么性能开销应该可以忽略不计。

还有另一种解决方案，我将其称为 (d)。也就是说，拥有与第一个表具有相同主键的另一个表以及其他列。当有多个不同的列形成一个自然分组时，这可能很有用。

简而言之，作为一般规则，我会选择（c）。它以最小的性能损失维护数据库的关系完整性。在某些情况下，我会选择（a）或（d），但这取决于问题以及什么被认为是“最佳”。

score 0 · Accepted Answer

看看 Scott Ambler 的关于将对象映射到关系数据库的主题的课堂论文，特别是比较策略的部分

2 回答 2