相关但不完全相同的事情：哪个更有效？（或者至少通读它对我没有任何帮助）
因此，我正在开发一个新站点（销售保险单），我们已经有几个站点（它是一个 Rails 应用程序）可以执行此操作，因此我在我的 sql 数据库中有一个称为策略的表。您可以想象它有很多列来支持所有可用的不同选项。
在这个新网站上工作时，我意识到我需要跟踪 20 多个选项。
我担心的是策略表已经很大了，但是现在它中的列几乎都被我们拥有的每个应用程序使用了。而如果我添加这些，它们将仅用于新站点，并且会在所有其余策略中留下大量空单元格。
所以我的问题是我是否将这些添加到现有表中或仅为该站点上出售的策略创建一个新表？另外我相信，如果我创建了一个新表，我可以从主策略表中省略一些列（但不是很多），因为此应用程序不需要它们。
“[A]lmost all used”表明您可以在考虑后更自然地拆分它。
现在，这里的大部分效率问题归结为三件事：
只有在很多情况下您需要一个特定的数据子集，而在另一批需要另一个子集的情况下，也许只有少数情况下您需要全部数据时，才真正出现第 2 点。如果您在大多数地方使用大多数列，那么它不会为您带来任何好处。在这种情况下，拆分表是不好的。
第 1 点和第 3 点分别支持和反对加入一张大桌子。
在此之前，让我们回到“几乎所有”。如果有几行带有一批空字段，为什么？经常回答“为什么？” 揭示了那里确实存在自然分裂，应该将其分解为另一个表作为正常标准化的一部分*. 字段的重复，是一个更大的建议，就是这种情况。
先做这个。
非规范化 - 无论是通过拆分自然是一个表，还是连接自然是多个表 - 都是一种非常特殊的优化类型 - 它以降低其他事物的效率为代价使某些事物变得更有效，并且它引入了可能导致错误的错误否则不存在。我永远不会说你永远不应该非规范化 - 我自己做 - 但你需要能够说“我正在以这种方式对表 X 和 Y 进行非规范化，因为它有助于案例 C 发生足够多的情况，我可以忍受额外的案例 D 的费用”。然后你需要检查它是否确实对案例 C 有显着的帮助，对案例 D 的帮助微乎其微，同时还要寻找隐藏成本。
首先归一化的原因之一是它在广泛的情况下提供了良好的平均性能。这是您大部分时间想要的平衡。从一开始就进行非规范化而不是以规范化数据库为起点几乎总是为时过早。
*有趣的琐事事实：“正常化”这个名称部分是对理查德尼克松的“越南化”政策的一部分，这意味着在某些方面存在一个笑话，将“-isation”添加到几乎任何东西上。如果不是因为白宫对春节攻势的反应，我们可能会使用“正常化”或完全不同的东西。