（注意这个情况并不完全是这样，但我以这个为例）
我在表中有一个实体，其中包含每 5 秒更新一次的数据（运动学数据：速度、航向、纬度、经度和位置时间），以及几乎不更新的其他数据，如果有的话（颜色、品牌、起源时间）。
alt text http://www.freeimagehosting.net/uploads/a67205e99e.jpg
现在我的老板希望我将这些数据分区到我们数据库中的单独表中（具有一对一关系），如下所示：
alt text http://www.freeimagehosting.net/uploads/1c699bc3c5.jpg
他说它应该是这种方式听起来“很明显”，但是将这些数据分开以便插入和更新真的有什么好处（例如，如果我在 Color 或 Make 上放置索引）？
【问题讨论】：
标签： sql database database-design indexing
像这样进行垂直分区可能是有意义的。或者它可能不会。
当您使用基于 MVCC 的引擎时，每次更新一行时，它通常*复制整行并创建一个带有修改的新行。这样一来，其他尚未看到更新的事务可以在需要时继续读取原始行。
这意味着在非常宽的行中频繁更新一些小列会导致数据库执行的写入操作超出其需要。
但不是很多，因为通常引擎只会同步其事务日志，无论未更新列的大小如何，它的大小都是相同的，并且还因为数据行通常存储在整个块中的块中无论如何都需要写，不管它有多少变化。
所以这听起来像是一个潜在的毫无意义的优化，与其他任何优化一样，应该考虑基于 a) 是否真的存在性能问题（即是否需要任何优化）和 b) 这种特殊的优化是修复它的最佳方法吗？
我认为 a) 的可能性不大，b) 的可能性也不大，因此需要这种可能性的可能性大约是不可能的平方。
* 一些引擎对非常大的列（例如大 BLOB 或文本列）例外，这些列保存在其他地方，如果行中的其他列被更新，则不会被复制。
【讨论】：
如果此设计的目的是维护运动数据的历史，那么该设计是有意义的。尽管CAR_KINEMATIC 表中似乎没有适合该用法的键。另一方面，如果这两个表之间存在一对一的关系，则划分是没有价值的。
【讨论】：
我不确定这个问题是否完全清楚。如果你想维护运动学的历史，那么适当的结构是将数据标准化为汽车数据和航向数据。汽车数据可以独立更新，总体上可能比运动学数据小得多。
如果您想保留汽车当前状态的平面记录，而不是保留历史记录，那么保留数据可能会更快。这样做的原因是，在大多数情况下，写入整个记录可能只需要一次写入操作。将其拆分为两个表可以保证至少有两个写操作。
在第一种情况下，您只是对数据进行规范化；在第二种情况下，当前的数据结构可能是最有效的。
垂直分区实际上并不常用（除非它是，见下文）。您可能希望使用垂直分区的一些场景是：
表很宽，只有一部分经常使用。例如，如果您有一个包含 250 列的表，其中 5 列经常更新状态更改，并且应用程序经常使用一小部分列。
出于安全原因，您可能会混合存在以 1:1 关系存在的机密数据和不太敏感的数据。您可以将机密数据移动到具有不同权限集的另一个表中。从历史上看，并非所有 DBMS 平台都允许您在列级别设置权限。
前两者的组合，其中某些字段的更改必须记录到审计表中，但其他字段的更新非常频繁，不需要记录。为了避免生成大量虚假的审计日志数据，可审计字段可以使用审计日志触发器存在于它们自己的表中。
最后，在某些情况下，您确实会在幕后获得垂直分区（即它在架构中不明确，但物理存储以这种方式工作）。例如，许多 DBMS 平台将 LOB 与普通表数据分开存储，这会导致表的一种隐式垂直分区。
事实上，这种特殊情况使得对具有 LOB 列的表进行操作非常昂贵，因此将 LOB 列移到单独的表中可能是垂直分区的一个很好的应用程序。
垂直分区的用途并不多，而且总是会增加额外 I/O 的开销。您需要避免大量开销或有特定原因（例如安全问题）才能使用它。
【讨论】：
你的老板是对的。而这与“分区”无关，也就是所谓的规范化。
编辑：好的，“垂直分区”是一个众所周知的术语，归一化是垂直分区的一种方法。但是在这种情况下，规范化似乎是正确的答案，它解释了这个问题（引用：“......将这些数据分开以便插入和更新真的有什么好处吗”）。标准化的优点和缺点是众所周知的。维基百科文章是一个很好的起点。
顺便说一句，为了保持“Erwin Smout”的火焰燃烧：“垂直分解”似乎不是这里常用的术语。对吧？
【讨论】：