关于数据主键的思考(乱七八糟的) 最后更新时间:2024年07月05日 ### 一、什么是主键 主键是由表中的一个或者多个字段构成,用来唯一标识表中的每一行记录。主键必须包含唯一值,不接受空值,一个表只能有一个主键。主键可以类比为学号、身份证号、车牌号或者 ID。主键可以提高查询效率,也可以保证数据的完整性和一致性。--来源:[https://zhuanlan.zhihu.com/p/605746797](https://zhuanlan.zhihu.com/p/605746797) ### 二、如何设计主键以及如何分析出一个数据中以何为主键 在数据库开发的范式中,阐述了不同范式下数据主键的定义和状态。如: 1)第一范式(1NF)。确保每个实体都有一个有效的主键,每个属性都依赖于主键,而且消除冗余的分组,以确保每个属性的原子性(不能有多个值存在)。第一范式包括了与通常称为关联实体的附加实体的多对多关系解析。 2)第二范式(2NF)。确保每个实体都有最小的主键,每个属性都依赖于完整的主键。 3)第三范式(3NF)。确保每一个实体都没有隐藏的主键,每个属性都不依赖于键值之外的任何属性(仅依赖于完整的主键)。 4)Boyce / Codd范式(BCNF)。解决了交叉的复合候选键的问题。候选键是主键或备用键。复合意味着不止一个(如一个实体主键有两个属性),交叉是指键与键之间隐藏着业务规则。 5)第四范式(4NF)。将所有三元关系分解成二元关系,直到这些关系不能再分解成更小的部分。 6)第五范式(5NF)。将实体内部的依赖关系分解成二元关系,所有联结依赖部分主键。 但是在实际开发中,并没有详细阐述如何去设计主键,如何去判断一条记录的什么字段可以成为主键。以下是我对于主键判断的一些思考和提出的方法。 主键是能够标识一条记录的唯一性的,也就是在一定程度上主键描述了或代表了某一事或物。那么逻辑上,在把数据放在某特定的业务场景下时(即上下文中),即使去掉了修饰词(即非主键的数据),依然不会改变主键的意义或主键所代表的主体。 例如,张三吃了一个红红的苹果。这是一个添加了修辞的陈述句,从句子中我们可以知道张三吃了一个苹果,以及这个苹果红红的。当我们在这个语境中所关注的是这一个动作时,我们可以知道“张三吃了一个苹果”。仔细回忆,我们会发现红红的这一修辞词的去留并不影响我们对干这一动作理解,修辞词只是加深了我们对于这一动作的细节的理解。因为这一主体是动作,而不是苹果。 因此,我们在设计和判断一张表的主键为何时,可以以下几个问句来作为评判标准的参考: 1. 这几个字段组合在一起是否可以代表某物或陈述事件?(如这是一个苹果,或某年某某地某个盒子被打开了,或今天三点下了雨) 2. 这几个字段是否为当前语境的关注主体? 3. 当前语境下是否具有唯一性? 代理键(也就是系统中常用的id作为主键)并不在该方法讨论范围内,事实上ID也只是映射的简单作用,是对ID所映射对像的符号化,就好比我们用“日”字来代表太阳,“月”字来代表月亮。理论上,代理键所代表的记录本身,也可以用上述办法来确定。 当然,这三个问句的适用性未必尽然,但可以作为参考。
Comments | NOTHING