SQL Server 2008，加入还是不加入？

Question

关于连接的一个小问题。我有一个包含大约 30 个字段的表，我正在考虑制作第二个表来存储其中的 10 个字段。然后我会加入他们的主要数据。我打算存储在第二张表中的 10 个字段没有被直接查询，它只是对第一张表中数据的一些设置。

类似：

Table 1
Id
Data1
Data2
Data3
etc ...

Table 2
Id (same id as table one)
Settings1
Settings2
Settings3

这是一个糟糕的解决方案吗？我应该只用一张桌子吗？它对性能有多大影响？表 1 中的所有条目也将在表 2 中具有一个条目。

小更新是有序的。大多数数据字段是 varchar 类型，其中 2 个是文本类型。如何处理索引？我的计划是索引 2 个数据字段，电子邮件（varchar 50）和作者（varchar 20）。 是的，表1中的所有记录都会有表2中的记录。大多数设置字段都是位类型的，大约80％。其余的是 int 和 varchar 之间的混合。 varchars 可以为 null。

Answer 1

这被称为vertical partitioning，是一种合法的策略。您可能出于以下原因这样做：

• 如果某些列的访问或更改频率远高于其他列。
• 如果您想将某些列存储在一组存储介质上，而将其他列存储在另一组存储介质上。
• 如果您有大量触发器不需要运行以响应某些列的更新。

通过 JOIN 访问时，性能可能会受到小幅影响，但在您只需要访问其中一个或另一个组件表的情况下，性能可能会有所提高。

Answer 2

这将取决于表 1 中的每一行是否需要表 2 中的一行（是否每一行都有设置）以及这些设置中有多少通常为 NULL。

如果所有设置（或大部分设置）都被使用并经常使用，我建议将它们放在同一张表中。

此外，您引用的列数并不极端，因此我建议使用单个表，如果使用字段则避免连接。

Answer 3

如果数据属于一起，则保持在一起。

如果您的设置在没有主表数据的情况下没有意义并且与它们一一对应（即 table1 中的一行恰好有一行是 table2），那么您应该将它们添加到主表中。

Answer 4

您的解决方案还不错，但请考虑以下事项：

1. 包含更多列且其中许多存储空值的表是创建另一个表的标志
2. 如果要存储设置，请创建一个可以存储任意数量的设置而不存储空值的设计，例如创建一个包含字段、primarykeyid、foreignkeyid、settingname、settingvalue 的表。 请注意，在 2 中，您存储的是设置名称的头部，但您使用 int 或 tiny int 它会执行得更好。

希望对你有帮助

Answer 5

表 1 和表 2 的行数是否相同？也就是说，表 1 中的每一行是否在表 2 中都有对应的行，反之亦然？如果是这样，不需要连接，您可以通过选择过滤掉您想要的列。

只有当表 2 中的行与表 2 中的多于 1 行对应时，连接才会有用，例如应用于多行数据的一行设置。

编辑：原始帖子中的编辑已经回答了我的问题。我想说这里不需要加入，只会对性能产生不利影响。

Answer 6

如果您打算在查询数据表的同时定期查询设置表，那么您将希望它们作为一个表。如果您分别查询每组数据，则将它们分开会很有用。

每次连接都会影响性能，但您还想了解您是如何使用这些表的。如果你同时需要它们，最好将它们放在一起，否则你可以将它们分开，只要你不打算将来经常同时使用它们。

Answer 7

除了索引方式之外，字段的大小、使用频率和类型（选择、更新等）以及表（行）的大小都很重要。

一般来说，如果一个表中的数据子集非常常见（例如在列表中），而第二个子集的查看/编辑频率要低得多和/或包含非常大的字段（如 varchar(最大限度））。

但是，如果始终一起查看数据，这可能不是要走的路。因此，如果您每次阅读第一个表格时都必须阅读第二个表格中的这些设置，请不要走这条路。

更新：考虑到您的索引以及几乎所有设置都是固定大小（位）的事实，我只想将其设为一张表。如果您需要一个没有整个表的子集查询，您可能需要考虑使用覆盖索引而不是拆分表。