将 VarChar(Max) [Notes] 列存储在同一个或单独的表中

Question

免责声明

不久前我有一个桌子设计的想法，当时对我来说很有意义。在最近的历史中，我意识到我有“过度设计”或花费太多时间试图“过度优化”解决方案的习惯。我假设这是我过度考虑解决方案并且会产生额外开销而几乎没有实际收益的情况之一。

题

假设一个对象（Shipment table例如 a）有某种NOTE varchar(MAX)我们想要跟踪的数据元素。在NOTE column有机会具有推到溢流数据，并大幅提高的大小row（因此限制的数量rows可以保存上page）。据我了解，这会对整个表上的各种操作的执行时间产生负面影响。

是否曾经有过我们应该将其column单独放置ShipmentNote table而不是将其保留column在Shipment table. 理论是，如果我们将 推NOTE column入一个单独的，table它会保存在pages上的Shipment table，从而使 上的所有操作Shipment table都能更好地执行。因为row尺寸更小，现在您可以rows在同一个page.

（请参阅下面的架构示例）：

这可能是一个好主意的主要用例是：

• 在Note column经常超过8000个字符（我认为这是当我们开始使用额外的分页）
• 在Note column仅在返回SELECT操作，很少或从未使用的部分JOIN或WHERE
• 其余columns的Shipment将要查询的独立的Note一个定期（IE：我们大部分的操作，也就无法使用Note，是JOIN或WHERE发生其他条件columns在`出货）

我看到的缺点（除此之外，在使用Shipment列外的表格时可能不会有明显的改进Note）：

• 现在变得不可能（或至少需要trigger或别的东西），以确保总有某种的值NOTE（IE：因为现在是一个独立的child table，我们不能保证NOTE为NOT NULL每一个row在Shipment
• 任何使用的操作NOTE现在都需要额外的努力，因为需要做一个JOIN以确保我们正在使用正确的记录

Answer 1

虽然您甚至在考虑这一点很棒 - 我认为这是微优化。SQL Server 已经内置了用于处理的优化NVARCHAR(MAX)，因此通常我会说在它成为问题之前不要再猜测它。但是，在阅读您的问题时，我想到了两个要点。

第一个是（正如您在最后一点中提到的那样）通过将数据拆分到另一个表而不是让 SQL Server 优化页面和数据本身，实际上会获得任何性能吗？我现在没有确凿的证据，但我怀疑没有。原因是，正如您所提到的，您的数据通常超过 8000 字节，因此无论如何都会被移动到 Note 表中的 LOB 页。您只会将感知到的问题从一张桌子移到另一张桌子。加上在JOIN必须获取数据时执行 a 的开销，您最终的情况可能会比开始时略差。

其次，当你标记数据库设计的问题，我的实际推荐的是，你不拆出来的音符到另一个表。然而，我的推理并不是由性能优化驱动，而是更具体地为应用程序增加灵活性。一件货件很可能需要附上不止一张纸条（例如，如果运输延误，或客户来电等……）。如果您在实际发货本身上有注释，则在不复制数据的情况下很难做到这一点。如果您将其提取到自己的表格中，您将能够为货件分配多个注释，并跟踪谁输入了这些注释以及何时输入。这使您的应用程序和数据库更加灵活。

如果您想优化，那么我建议您无需查询笔记，除非有人特别想查看它们（例如在您的应用程序中有专门的表单来这样做）。这样，您只需要在有人明确想要查看数据时执行联接/查找。即使您没有将注释外部化到另一个表中，如果不需要，则不在查询中包含该列将消除 SQL Server 读取 LOB 页的需要。如果可能的话，在微观层面优化之前，我总是优化查询以返回所需的最少信息量。