是否根据第三范式将"ID"字段添加到数据库表中？

Question

是否可以将"ID"字段作为主键添加到我的所有数据库表中,还可以使用它来使表之间的关系发生？这种设计是否会被视为3NF(第三范式)设计？如果是,理论上是否推荐这个东西？

Answer 1

问题是问题有点孤立.但既然你担心这个问题是否具有理论上的(并且可能是符合标准的),那么答案就不应该那么孤立.

如果是,理论上是否推荐这个东西？

不,它没有任何学术或理论依据.它打破了基本的关系数据库设计规则,因此(a)不会生成关系数据库和(b)生成的任何内容,将不具备用户(无需通过应用程序)期望通过关系功能的能力许多简单的关系数据库报告工具.

实际上,不幸的是,制作电子表格(应用程序开发人员已经为他们的应用程序确定)的非常常见的,下意识的,快速而肮脏的方法适合于诸如MS SQL 的"数据库" 容器. 无需进行任何正确的数据库设计或建模工作,这些工作是容器内容符合关系数据库所必需的.有利于获得原型或概念证明但尚未准备好进行任何形式的开发(SQL编码).

是否可以将"ID"字段作为主键添加到我的所有数据库表中,还可以使用它来建立表之间的关系？

不挂断.根据定义,它们不能是"数据库表".数据库表是通过正式的建模过程得出的,因此将具有强大的标识符.关系已经定义.在这种情况下,不会问这个问题.因此,由于它被问到,你所询问的事情远不及"数据库表".他们只是一个app应用程序的开发人员暂存器.

将FK约束添加到一个电子表格,将其"关联"到另一个电子表格,并添加"ID"PK,不会形成"关系""数据库".不,它仅使用SQL的功能来关联容器中其他不相关的电子表格.它们仍然是不相关的电子表格,通过添加的 "ID"列"链接" .

结果是,数据大量重复; 更新异常; 更多指数; 更大的"关系"数据集; 表现不佳; 大量过度使用临时表; 复杂的SQL,所有这些都可以通过真正的数据库设计来避免.

这种设计是否会被视为3NF(第三范式)设计？

规范化是数据库设计过程的一部分(并非全部).3NF是通过这个过程来实现的.3NF或任何NF,不是可以放置在电子表格集或容器的部分设计内容上的标签,而不经过整个过程,从而获得徽章.一个人不会"考虑"一堆电子表格或部分设计的内容3NF; 一个人评估是否遵循了规范化规则,如果规则没有被违反,则它被公平地标记为3NF.由于没有遵循标准化过程,因此没有理由认为它可能与任何标准形式有关.

同样,除了规范化之外,如果在流程中遵循了关系数据库规则,并且没有违反,则可以实现对关系数据库标准的遵从性.由于没有遵循关系数据库方法,因此没有理由建议它可能与任何关系数据库标准相关,或者可以从中预期任何关系数据库.

理解整个问题

"ID"是代理键.代理键总是(你是对的)一个额外的键和索引,除了预先存在的PK,它即将被篡夺.当然,每次访问都会产生相当大的性能成本.

一些提问者认为可以使用代理键来代替 PK.当然,这是错误的,你意识到这一点,所以感激不必在这里解决.

"所有替代钥匙"或"没有替代钥匙"的概念是那种对于儿童来说是正常的黑或白,全有或全无的废话,但对于成年人,特别是从事IT工作的人来说是不可接受的,需要精确和理解.对于一个小孩子来说,"如果爸爸不让我做我想做的事,他就不爱我",这是很正常的,因此"如果他不爱我,他就恨我".我们大多数人都意识到生活比小学时代要复杂得多."喜欢"在每张桌子上看到"ID"并且"不喜欢"在某些桌子上缺少它们的开发者,根据定义,无法将数据库视为一个整体,以及其他开发者和用户的需求;

它也不是关于灰色阴影或模糊定义.不,这些定义在30年内没有改变(它们已经扩展并且更加精确,但它们没有改变).灰色阴影允许开发人员避免合规性和标准.所以也不建议这样做.

什么是真正的关系数据库？

事实上,如果数据库是由合格的数据建模者诚实地建模和设计的,使用已有30年的方法,他们最终会得到一个真正的关系数据库.如果他们不遵循这个过程,它既不会关系也不会是数据库.标识符和关系已经被定义,其含义和背景将贯穿各种表格.数据将被标准化为3NF或BCNF或5NF,并且不存在更新异常.在最后一步中,作为正式过程的一部分,而不是在它之外,在将逻辑转换为物理时,建模者可以提高某些性能标识符通过添加代理键,并避免将大(宽)键带入相关的子表(1).从另一种方法再次证明,为什么零替代品或所有代理人的概念都是幼稚的,并且完全脱离了真正的过程.

真正的Relational数据库将具有完整的Relational功能,3NF的诚实成就,使用自然的Relational密钥,少数几个被认真地切换到Surrogates.

很容易证明

当然,我所说的一切都可以很容易地证明:只需发布5到10个电子表格的DDL,我需要至少4个"深度"(great.grand.parent⇢grand.parent⇢parent⇢child).

您可能感兴趣,我最近在相关问题中发布了您的问题信息,我在此不再重复.

注意

1. 这只是必需的,因为当前的SQL产品不支持完整的关系模型,并且消除了它们所具有的已知性能障碍.如果供应商提供关系数据库,其中广泛的关系密钥执行以及狭窄的关键数据库,则没有必要.

2. 我同意Erwin关于密钥和标识符的陈述,因此我没有在我的答案中重复它们.

Answer 2

"将"ID"字段添加为我的所有数据库表的主键是否可以使用它来使表之间的关系发生？

你明确打算在任何地方添加代理ID,盲目而无需任何思考.认为没关系就像做它一样愚蠢."好"标识符具有唯一性的属性(否则它不会是很明显的标识符),稳定性(它们的值很少变化)和熟悉性(它们的值表示用户世界中有意义的东西 - 外面的世界IT系统).

请注意,我故意使用"标识符"一词而不是"键".根据定义,键具有唯一性.因此,所有密钥都是用作标识符的有效候选者.您实际选择用作标识符的哪个键应取决于某个特定键还满足稳定性和熟悉度标准的程度.

自然键可能不足以满足稳定性标准(但是它们所做的程度通常是过度强调的,通常是那种对用户方面考虑太少而对问题本身方面过多的开发人员).系统生成的ID严格违反"熟悉度"标准.

这些考虑因素应该足以证明在对另一方进行权衡时,平衡应该主要采用哪种方式.

"这个设计是否会被视为3NF(第三范式)设计？如果是,理论上是否推荐这个设计？"

如果您"将ID列添加到现有设计",那么这不会影响NF.无论您现有的设计是什么NF,添加ID的设计都将具有相同的NF.