当前位置：文江博客话题详情

单个表中的列太多 - 这是好的范式吗？

发布于 2024-07-13 01:19:37 字数 72 浏览 5 评论 0原文

规范化表应该具有较少数量的列，并且可以具有尽可能多的引用字段。这是正确的做法吗？列数和良好的标准化过程之间有什么关系吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

泡沫很甜 2024-07-20 01:19:38

两者之间有什么关系吗？
列数和良好的
标准化过程？

简而言之，不。 3NF 规范化表将具有所需数量的列，前提是

表中的数据是相关的
在钥匙上，整个钥匙，什么也没有
但关键（所以帮助我科德）。

在某些情况下，（某些）非规范化实际上可能会提高性能，而衡量何时应该这样做的唯一真正衡量标准是对其进行测试。

回复收藏 0 原文

请别遗忘我 2024-07-20 01:19:38

您应该遵循规范化原则，而不是关心表中的列数。业务需求将驱动实体、实体的属性及其关系，并且没有绝对的数字是“正确的”数字。

回复收藏 0 原文

指尖上得阳光 2024-07-20 01:19:38

如果您觉得表的字段太多，可以使用以下方法。示例：-

CREATE TABLE Person
    Person_ID int not null primary key,
    Forename nvarchar(50) not null,
    Surname nvarchar(50) not null,
    Username varchar(20) null,
    PasswordHash varchar(50) null

该表代表人员，但显然并非所有人员都需要成为用户，因此 Username 和 PasswordHash 字段可为空。然而，人数可能比用户多 1 或 2 个数量级。

在这种情况下，我们可以创建一个 User 表来保存 Username 和 PasswordHash 字段，并与 Person 表建立一对一的关系。

您可以通过查找可空字段集来概括此方法，这些字段要么一起为空，要么一起具有值并且很可能为空。这表明您还可以提取另一个表。

编辑

感谢斯蒂芬妮（参见评论），这种技术显然被称为“垂直分区”

Here is an approach you can use if you feel your table has too many fields. Example:-

CREATE TABLE Person
    Person_ID int not null primary key,
    Forename nvarchar(50) not null,
    Surname nvarchar(50) not null,
    Username varchar(20) null,
    PasswordHash varchar(50) null

This table represents people but clearly not all people need be users hence the Username and PasswordHash fields are nullable. However its possible that there will be 1 or 2 orders of magnitude more people than there are users.

In such case we could create a User table to hold the Username and PasswordHash fields with a one-to-one relationship to the Person table.

You can generalise this approach by looking for sets of nullable fields that either null together of have values together and significantly likely to be null. This indicates that there is another table you could extract.

Edit

Thanks to Stephanie (see comments) this technique is apparently called "Vertical Partitioning"

回复收藏 0 原文