我有一张有一堆字段的表。这些字段可以分成逻辑组——比如工作的项目经理信息。分组本身并不是真正的实体候选者，因为它们没有也不应该有自己的 PK。
现在，为了对它们进行分组，这些字段具有前缀（例如 PmFirstName），但我正在考虑将它们分成多个表，在主表上具有 1:1 的关系。
当我这样做时，有什么需要注意的吗？这只是一个糟糕的选择吗？
我可以看到，也许我的查询会因为所有额外的连接而变得更加复杂，但可以通过视图来缓解，对吗？如果我们谈论的是一个少于 10 万条记录的表，这会对性能产生显着影响吗？
编辑：我将进一步证明非实体候选人的想法。此信息由我们的用户群输入。他们不了解/不关心彼此。因此，同一个用户可能会提交相同的“projectManager 名称”或任何在这一点上不会违反任何约束的东西。如果我们想关联来自不同用户的条目，我们可以稍后确定。如果我给这些东西自己的键，它们将以与主表相同的速度增长——因为它们本质上是同一个实体的一部分。没有 pt 是用户从可用的“项目经理”列表中挑选的。
因此，鉴于上述情况，我认为它们不是实体。但也许不是 - 如果您有进一步的想法，请发布。
除非有特定的性能原因，否则我通常不使用 1 对 1 关系。例如，将不常用的大文本或 BLOB 类型字段存储在单独的表中。
我怀疑这里还有其他事情发生。在您给出的示例中 - PmFirstName - 似乎应该有一个与“ProjectManagers”或“Employees”表相关的单个 pm_id。您确定这些分组都不是真正的实体候选人吗？
对我来说，它们闻起来很臭，除非对于某些行或查询，您不会对额外的列感兴趣。例如，如果对于大部分查询，您没有选择 PmFirstName 列，或者对于大部分行，这些列是 NULL。
我喜欢气味标签。
我将 1 对 1 关系用于类似继承的构造。
例如，所有债券都有一些基本信息，如 CUSIP、Coupon、DatedDate 和 MaturityDate。这一切都在主表中。
现在，每种类型的债券（Treasury、Corporate、Muni、Agency 等）也有自己独特的一组列。
在过去，我们只会有一张非常宽的桌子，里面有所有这些信息。现在我们将特定类型的信息分解成单独的表，这给了我们更好的性能。
现在，为了对它们进行分组，这些字段具有前缀（例如 PmFirstName），但我正在考虑将它们分成多个表，在主表上具有 1:1 的关系。
创建一个人表，每个数据库都需要这个。然后在您的项目表中有一个名为 PMKey 的列，它指向人员表。
为什么感觉这组字段不是实体候选项？如果不是，那么为什么要尝试用前缀来识别它们呢？
删除前缀或将它们提取到自己的表中。
如果它们是可以在其他地方使用的单独的逻辑实体，那么将它们分成单独的表是很有价值的。
因此，“项目经理”可能与当前的所有项目是 1:1 的，但稍后您可能希望项目经理拥有多个项目是有道理的。所以有额外的桌子很好。
如果您有 PrimaryFirstName、PrimaryLastName、PrimaryPhone、SecondaryFirstName、SecondaryLastName、SEcondaryPhone
您可以只拥有一个包含 FirstName、LastName、Phone 的“Person”表
那么您的原始表只需要“PrimaryId”和“SecondaryId”列来替换您之前拥有的 6 列。
此外，使用 SQL，您可以跨物理位置拆分文件组和表。因此，您可以有一个具有 1:1 关系的 POST 表和一个 COMMENT 表，但 COMMENT 表位于不同的文件组上，并且位于具有更多内存的不同物理驱动器上。
1:1 并不总是有气味。除非没有目的。