Database 是否加入？’；ID"；字段到数据库表的第三个标准格式是否被认为是错误的？

是否可以将“ID”字段作为主键添加到所有数据库表中，并使用它在表之间建立关系？ 这个设计会被认为是3NF（第三范式）设计吗？

---

如果是的话，这个东西理论上推荐还是不推荐？

如果我理解正确

是的，向表中添加一个序列ID，并让该ID成为您引用该表行的主键，这通常是一个很好的设计问题。是否违反3NF：它不违反3NF，但也不能保证它

实际上，添加一个串行ID并在内部使用该值有其优点。一个是您控制ID，而外部生成的密钥可能会被另一方突然更改。另一方面，将ID导出到其他方会“绑定”该密钥，因为在您这方面更改它可能会影响其他方对该密钥的使用。此外，序列号通常很容易伪造，并且可能与其他人使用该号码发生冲突

---

同样在实际的数据库设计中，3NF或Boyce Codd往往是您渴望的理论想法，而不是盲目遵循。选择性非规范化是一种通过使数据更靠近而加速某些查询的已知技巧。

我完全同意@jlouis的观点，即3NF或Boyce Codd倾向于理论观点

---

从我的实践中，我可以说，只有在像查找表这样的引用中使用自然键才是一个不错的选择，前提是真实世界中的键字段是唯一的，不是空的，并且不随时间变化。我认为，在其他情况下，使用代理键更可取（从我的角度来看）：尽管3NF或Boyce Codd告诉我们所有的事情，但它只是设计表的更方便的方式。

范式涉及属性之间的依赖关系。如果不知道要在表中表示哪些依赖项，我们就无法确定它是否满足任何特定的范式

如果您谈论的是代理键（在业务领域中没有任何意义的键），那么对于大多数目的来说，重要的一点是这样一个键不应该是任何表的唯一键。您通常也应该有一个自然键（也称为业务键），以确保数据不重复。

是否可以将“ID”字段作为主键添加到所有数据库表中，并使用它在表之间建立关系

你显然有意在任何地方添加代理ID，盲目且不加任何思考。认为那是好的和做那件事一样愚蠢。“好的”标识符具有唯一性（否则它显然不是什么标识符）、稳定性（它们的值只会偶尔更改）和熟悉性（它们的值表示用户世界中有意义的东西——it系统之外的世界）

请注意，我非常有意地使用了“标识符”一词而不是“键”。根据定义，键具有唯一性属性。因此，所有密钥都是用作标识符的有效候选密钥。您实际选择哪个键作为标识符，应该取决于某个特定键满足稳定性和熟悉性标准的程度

自然密钥可能不足以满足稳定性标准（但它们满足的程度通常是过度强调的，通常是那些对用户方面考虑太少而对问题本身考虑太多的开发人员）。系统生成的ID绝对肯定会违反“熟悉度”标准

这些考虑因素应足以证明，在以一种为另一种进行交易时，余额应主要流向何方

“这个设计会被认为是3NF（第三范式）设计吗？如果是的话，这是不是理论上的建议？”

---

如果“将ID列添加到现有设计”，则这不会影响NF。无论您现有的设计在哪个NF中，添加了ID的设计都将具有相同的NF。

问题是，问题有点孤立。但是，由于您担心这个问题是否有理论基础（可能还有符合标准的基础），所以答案不必如此孤立

如果是，理论上是否推荐该产品？

没有。它没有任何学术或理论基础。它打破了基本的关系数据库设计规则，因此（a）不会生成关系数据库，（b）无论生成什么，都不会具有用户（无需通过应用程序）通过许多简单的关系数据库报告工具所期望的关系能力

事实上，不幸的是，这是一种非常常见的、下意识的、快速的、肮脏的将电子表格（应用程序开发人员已经为他们的应用程序确定了电子表格）放入“数据库”容器（如MS SQL）的方法而不进行容器内容作为关系数据库所需的任何真正的数据库设计或建模工作。很适合于原型或概念验证，但不适合任何形式的开发（SQL编码）

是否可以将“ID”字段作为主键添加到所有数据库表中，并使用它建立表之间的关系？

等一下。根据定义，它们不能是“数据库表”。数据库表是通过正式的建模过程得到的，因此具有强大的标识符。以及已经确定的关系。在这种情况下，不会提出这个问题。因此，由于它是被询问的，所以您所询问的内容与“数据库表”相差甚远。他们只是一个应用的开发者，一个应用的草稿

将FK约束添加到一个电子表格，将其与另一个电子表格“关联”，并添加“ID”PK，并不构成“关系型”数据库。不，它只使用SQL的功能来关联unr