考虑下面的数据结构，其中用户具有少量固定设置。
[Id] INT IDENTITY NOT NULL,
[Name] NVARCHAR(MAX) NOT NULL,
[Email] VNARCHAR(2034) NOT NULL
[SettingA],
[SettingB],
[SettingC]
将用户的设置移到单独的表中是否正确，从而与users表建立一对一的关系？这是否比将用户存储在与用户相同的行中提供了任何真正的优势（明显的缺点是性能）。
答案 0 :(得分：7)
当表格非常宽（即有很多列）时，通常会将表格分成两个或多个1：1相关表格。程序员很难处理包含太多列的表。对于大公司来说，这样的表格可以轻松拥有超过100列。
想象一下产品表。有一个售价和另一个价格，仅用于计算和估算。拥有两个表，一个用于真实值，一个用于规划阶段，这不是一件好事吗？所以程序员永远不会混淆这两个价格。或者采取产品的逻辑设置。您想要插入到products表中，但是在其中包含所有这些逻辑属性，您是否需要设置其中的一些？如果是两个表，则会插入到产品表中，另一个负责物流数据的程序员会关心后勤表。没有更多的混乱。
许多列表的另一个问题是，对于具有150列的表而言，全表扫描当然比对于只有一半或更少的表的表更慢。
最后一点是访问权限。使用单独的表，您可以在产品的主表和产品的逻辑表上授予不同的权限。
总而言之，看到1：1的关系是相当罕见的，但是他们可以更清楚地了解数据，甚至可以帮助解决性能问题和数据访问。
编辑：我正在接受Mike Sherrill的建议，并（希望）澄清关于规范化的事情。规范化主要是关于避免冗余和相关性缺乏一致性。是否仅在一个表或更多1：1相关表中保存数据的决定与此无关。您可以决定在一个表中拆分用户表，以获取个人信息，如姓名和他的学校，毕业和工作。两个表都将保持原始表格的正常形式，因为没有比以前更多或更少冗余的数据。使用两次的唯一列是用户ID，但这不是多余的，因为在两个表中都需要它来标识记录。
因此询问“将设置规范化为单独的表是否正确？”这不是一个有效的问题，因为您没有通过将数据放入1：1相关的单独表格来规范化任何事情。
答案 1 :(得分：2)
创建具有1-1关系的新表不是一个合理的解决方案。您可能有时需要这样做，但通常没有理由有两个表，其中用户ID是主键。
另一方面，将设置拆分为单独的表，每个用户/设置组合一行可能是一个非常好的主意。这将是一个三表解决方案。一个用户，一个用于所有可能的设置，一个用于它们之间的联结表。
联结表非常有用。例如，它可能包含设置的有效日期和结束日期。
但是，这假设设置类似于＆＃34;在SQL意义上，彼此之间。如果设置不同，例如：
然后在将它们存储在表中时会出现数据类型问题。所以，答案是＆＃34;它取决于＆＃34;。很多答案取决于设置的外观，使用方式以及对它们的约束类型。
答案 2 :(得分：1)
你们都错了:)开玩笑吧。
在非常高负载，大容量，高度更新的系统上，将表按1：1拆分有助于优化I / O。
例如，通过这种方式，您可以将大量读取的列放在单独的物理硬盘驱动器上，以加快并行读取的速度（为此1-1表必须位于不同的“文件组”中） 。或者，您可以优化表级锁。等等
但是这种优化通常不会发生，除非您拥有数亿行的行和巨大的读/写并发性
答案 3 :(得分：0)
通常不会将表拆分为不同的表，它们之间的关系为1：1，因为：
如果关系真的 1：1，则完整性强制执行归结为＆＃34;在所有相关表中插入，或者根本不执行＃34;。在服务器端实现这一点需要支持延迟约束检查的系统，以及AFAIK，它是相当高端系统的一个特性。因此，在许多情况下，1：1强制执行被推送到应用程序端，这种方法有其明显的缺点。
尽管如此，建议拆分表的情况是，当存在安全性视角时，即当一个用户不能更新所有列时。但请注意，根据定义，在这种情况下，表之间的关系永远不能严格 1：1。
（我还建议你仔细阅读 Thorsten / Mike之间的讨论。你使用了＃normal;＆＃39;标准化＆＃39;但是规范化与你的情景没什么关系 - 除非你正在考虑6NF，我认为这不太可能。）
答案 4 :(得分：-1)
更有意义的是，您的设置不仅位于单独的表中，还使用ID和设置之间的多对多关系。这样，您可以根据需要设置尽可能多的（或少数）设置。
<强> UserSettings
[Settings_ID]
[User_ID]
[Settings]
事实上，人们可以为[电子邮件]字段提出相同的论点。