相关疑难解决方法(0)
当我可以使用其他人作为关键字段时，为什么要创建 ID 列？
可能的重复：
为什么使用 int 作为查找表的主键？
到目前为止，我习惯于为每个表创建一个 ID 列，它的实用性使我不必考虑有关主键理论的决策。
我大学的教授建议全班从一个或多个字段制作主键，这些字段构成关于每一列的一个唯一信息。是的，我想养成使用自然键而不是代理键的习惯。维基百科上列出了代理键的优缺点，我严格推荐这篇文章
我见过人们对所有内容都使用整数 ID 字段，但没有人评判这种方法，因为
- 它“看起来”高效
- 使用了一个数字字段，它看起来更酷，因为它在内存中每行的大小
我开始认为额外的 ID 字段只是创建冗余数据而没有实际好处。那么当我可以使用其他列作为关键字段时，为什么还要创建 ID 列呢？
- 如果您的 ID 字段是 32 位，则它已经相当于 4 个 ASCII 字符。
- 如果您的 Id 字段是64 位整数，则它是8 个字符的字符串，因此它实际上并没有节省那么多内存（这里暗示的是用于比较的内存。额外的 id 列已经添加到使用的内存中（HDD 和 RAM） ) )
- 额外的 ID 字段会使您的索引成本加倍，因为您还将索引一个可以用作主键的唯一字段。
- 如果您需要可以用作关键字段的数据，则进行额外的联接，例如，如果您在一篇博客文章中存储了唯一的用户 ID，以显示作者姓名，则进行联接查询，如果您的密钥字段是作者的名字，你不需要加入，因为你将相关数据存储在博客帖子表中。具有有意义数据的外键字段减少了子查询或连接的需要
- 创建一个额外的 id 字段“添加”到内存负载，它不是唯一字符串字段的替换，您不是用整数替换 char-varchar 字段，而是添加一个额外的列并创建额外的数据流。所以任何数据存储的比较都应该在“string”和“int+string”之间进行。添加整数 id 字段不节省空间。
另一方面
- 分配从用户输入中获取价值的主键数据可能会出现问题，因为人们可能会输入错误的社会安全号码，并且由于独特的政策，想要注册的实际人员将无法注册。这可以通过在原始号码上添加一个或多个额外数字来规避。
额外资源：
我从阅读文章中得出的结论是，我应该尽可能使用自然键，而不是每次都跳过考虑自然键并使用代理键，好像这是一个标准。
推荐指数
解决办法
查看次数
在关系数据库中查找表的最佳实践是什么？
查找表（或一些人称之为代码表）通常是可以为特定列给出的可能值的集合。
例如，假设我们有一个名为party（用于存储有关政党的信息）的查找表，它有两列：
party_code_idn，它保存系统生成的数值，并且（缺乏业务领域含义）用作真实键的代理。party_code, 是表的真实或“自然”键，因为它维护具有业务领域内涵的值。
让我们说这样的表保留了以下数据：
+----------------+------------+
| party_code_idn | party_code |
+----------------+------------+
| 1 | Republican |
| 2 | Democratic |
+----------------+------------+
在party_code列，这使价值“共和”和“民主”，在工作台的真正的关键，是建立了一个独特的约束，但我需要添加的party_code_idn，它定义为表（的PK虽然，从逻辑上说,party_code可以作为 PRIMARY KEY [PK])。
题
指向事务表中的查找值的最佳实践是什么？我应该建立外键 (FK) 引用(a)直接指向自然和有意义的值还是(b)代理值？
选项（a），例如，
+---------------+------------+---------+
| candidate_idn | party_code | city |
+---------------+------------+---------+
| 1 | Democratic | Alaska |
| 2 | Republican | Memphis …推荐指数
解决办法
查看次数
外键 - 使用代理或自然键的链接？
表之间的外键是否应该链接到自然键或代理键是否有最佳实践？我真正找到的唯一讨论（除非我的 google-fu 缺失）是Jack Douglas 在这个问题中的回答，他的推理对我来说似乎是合理的。我知道除了规则改变之外的讨论，但这在任何情况下都需要考虑。
提出这个问题的主要原因是我有一个遗留应用程序，它使用带有自然键的 FK，但是开发人员强烈推动转向 OR/M（在我们的例子中是 NHibernate），并且一个 fork 已经产生了一些破坏性更改，因此我希望使用自然键将它们推回正轨，或者移动旧应用程序以使用 FK 的代理键。我的直觉告诉我要恢复原始的 FK，但老实说，我不确定这是否真的是正确的道路。
我们的大多数表都已经定义了代理键和自然键（尽管是唯一约束和 PK），因此在这种情况下，必须添加额外的列对我们来说不是问题。我们使用的是 SQL Server 2008，但我希望这对于任何数据库都足够通用。
推荐指数
解决办法
查看次数
第三范式：复合 PRIMARY KEY 与系统生成的代理 (IDENTITY)
我正在研究一个数据建模项目，我正在尝试为一个history只有四列的表找出最好的数据建模方法：
CREATE TABLE FooHistory
(
SecurityID INT (FK), -- Part of the natural PK.
FieldID INT (FK), -- Part of the natural PK.
DateCreated DATETIME2(0), -- Part of the natural PK.
Value VARCHAR(50)
);
此表中的自然复合 KEY 将是(DateCreated, SecurityId, FieldID)，并且 ETL 过程每 30 分钟将向此表添加 ~ 2K 行。
问题
声明复合 PRIMARY KEY (PK)
(DateCreated, SecurityId, FieldID)与添加新 IDENTITY 列（即系统生成的代理）并将其用作 PK 的优缺点？我相信，如果我添加一个 IDENTITY 列并将其用作 PK，那么该表将不会处于第三范式（3NF）中，因为非 PK 列之间将存在函数依赖关系，即，
(DateCreated, SecurityId, FieldID)和Value.由于此表保留了历史数据，因此我不希望将此表加入其他外部表，应用程序将主要使用 SELECT 语句与其进行交互。基于这些假设，将表保持在 …
推荐指数
解决办法
查看次数