关于每一个数据库表都应该有一个单一的字段作为主键的讨论.pdfVIP

关于每一个数据库表都应该有一个单一的字段作为主键的讨论 2010 年 5 月 6 日更新: 只有真正懂得了这个道理的人, 才算真正理解了关系数据库. 如何才 算懂得了这个道理? – 即使你有一百个理由要用关联主键, 你也能找到这唯一的一个理由放 弃, 改而使用单一字段做主键. —— 在数据库设计中, 每一个表都应该有一个字段作为主键. 这个字段一般是自增整数字段, 或 者某些数据库支持的自动产生不重复字符串的字段, 也可以是程序自己产生的唯一标识. 总 之, 每一个数据库表都应该有一个单一的字段作为主键. 使用单一的字段作为表的主键, 有许多优点. 最重要的一条是可以通过一个原子属性 (如整数, 字符串)来标识一行记录. 一旦可以方便地标识一行记录, 那么数据的查询, 更新, 删除也都 非常简单. 如果一个表没有主键, 那么必须通过一行记录本身才能标识一行记录. 也就是, 你必须知道 一行记录的每一个字段的值, 才能在 SQL 语句中操作这条记录. 数据库表支持联合主键, 也就是使用表的至少 2 个字段作为主键. 使用联合主键的缺点和不 使用主键的缺点有很大的相似性, 因为当联合主键所使用的字段越多, 联合主键的缺点就越 来越趋近于不使用主键, 直到表的所有字段作为主键时, 和不使用主键几乎是完全相同的 – 除了前者不能存在重复行, 作为主键的字段一般使用自增整数字段, 因为绝大多数关系型数据库管理系统都支持这种字 段类型, 而且速度快, 占用空间少. 一个害怕使用自增整数字段作为主键的理由是自增整数 会回绕从而导致重复. 但这种担心是没有必要的. 对于最普通的 32 位无符号整数, 其最大值 是在 Mysql 中是 4294967295(43 亿) , 如果数据库表以每秒 1 条的速度保存记录, 那么一天 也只能 86400 条 (约 10 万条)记录, 需要 49710 天(约 136年)之后才能发生重复. 幸运的是, 绝大多数系统产生数据的速度比这个假设慢得多了. 如果系统产生数据的速度确实足够快速, 则可以使用 64 位的长整型整数. 如果确实需要联合主键, 则可以使用 UNIQUE 索引来代替. 任何不得不使用联合主键的需求, 都是基于对关系数据库的错误理解而产生的. 并不是要用单一主键来覆盖复合主键的需 求, 而是在表设计中, 单一主键是必须的, 用联合唯一索引来覆盖’复合主键’的需求. 一个例子: 表 1: 使用联合主键 (只是作为反面例子出现, 它应该被联合唯一索引代替) table_a{ field_a: PK; field_b: PK; field_…: PK field_c; } 表 2: 不使用联合主键 table_b{ id: PK; field_a: UNIQUE; field_b: UNIQUE; field_…: UNIQUE field_c; } * 联合主键导致数据操作复杂化 这两种表定义都能反映相同的业务模型. 使用联合主键对保存数 据的程序代码影响不大, 情况 1 通过联合主键保证不会产生重复 数据, 但情况 2 通过联合唯一索引保存不会产生重复数据. 但对 查找操作有不良影响, 同时影响到使用了查找功能的更新和删除操作. 考虑查找特定几条记 录的情况: 表 1: 查找 (field_a, filed_b, …) = [(1, 2, ...), (1, 3, ...), (2, 4, ...), ...] 这 几条记录. 表 2: 查找 id = [1, 2, 3, ...] 这几条记录. 显然, 表 2 的描述更简洁, 从而使程序代码和 SQL 语句更简洁. 如果把所有的字段都作为主 键, 那么表 1就不存在查找特定几条记录的功能了, 因为已经知道, 所以不必再找. 这是一 种最极端的联合主键的副作用, 联合主键的字段越多, 就越趋向于这种极端. * 联合主键不利于表示关系 联合主键不利于表示关系, 是因为它会造成不必要的冗余. 考虑有另外两个表, 需要分别 关联 table_a 和 table_b: table_ac{ id; table_a_field_a; table_b_field_b; … } table_bc{ id; table_b_id; } 显然, 不使用联合主键可以减少冗余. 如果使用所有