SQL Server数据库设计 - 我们应该规范化具有多列的键

Question

我正在设计一个新的数据库，并专门处理一组具有以下关系的元素。

1. 每个SerailNumber（SNo）可以有一个或多个车道（最大车道= 15）
2. 每个车道可以有一个或多个房间（最多房间数= 20）每个
3. 商会可以有一个或多个单位（最大单位= 4000）
4. 每个单元可以只有一个值

因此每个值由复合键（SNo，LaneNo，ChamberNo，UnitNo）确定。如果我把它放在一个表中，它将如下所示：

==========================================
| SNo| LaneNo | ChamberNo | UnitNo | Value |
==========================================

由于Lanes和Chambers的数量很小，因此数据类型可能很小。然而，由于我们每个室可以有4000个单位，我们将重复三列（SNo，LaneNo，ChamberNo）4000次。我的问题是：

上述设计是否在规范化规则或我如何构建主键方面存在任何问题？将（SNo，LaneNo，ChamberNo）放在一个具有唯一ID的单独表中并使用该唯一ID作为UnitNo和Value的键是更好的解决方案吗？

我正在寻找具有使用类似数据依赖性经验的人的建议。

Answer 1

主键选择是数据库规范化的一部分。第一范式要求选择主键。主键可以是单列或多列。您通常会根据预期用途选择主键。列或列的组合必须唯一标识单个行（在SQL服务器中都不能为空）。

由于第二范式以父表上的主键的外键关系的形式定义相关表，因此非常期望（被许多人视为要求）构成主键的列永远不会改变值。

由于这些原因，诸如social_security数字的phone_number之类的自然键不会被用作主键，因为它们确实会发生变化（或者最初被误导）。因此，许多人设计具有代理键（例如身份值）的表并在任何地方使用它。就个人而言，我并非迂腐，但很少使用自然键，除非它与不太可能改变的东西联系在一起，例如美国州代码。 SSN不是一个好的选择，因为其他考虑因素，例如重复SSN（它们确实存在）以及除非您有合法理由，否则不应暴露SSN。

在连接记录时，使用小型主键而不是多个大型列具有明显的性能优势。您通常需要在自然键列上使用二级索引。

您可能需要阅读basic normalization上的文章。第3范式通常被认为是最佳设计的最佳第一近似值。