IDC表设计规范说明.pdf

. 数据库表设计规范 目的 为了规范数据库设计，减少设计失误，提高数据安全及性能，特制订本规范。 适用范围 适用本系统 数据库。原则上，数据库设计应遵循本规范说明，特殊情况可例外，但需说明原 MySQL 因。 规范 命名 1.库名、表名、字段名必须使用小写字母 ,命名有需要的话采用下划线分割 2.库名、表名、字段名禁止超过 32 个字符 3.库名、表名、字段名支持最多 64 个字符 ,但为了统一规范、易于辨识以及减少传输量 ,禁止超过 32 个字符。 4.库名、表名、字段名禁止使用 MySQL 保留字 表 1.减少或避免使用临时表； 2.每一个表都需要设置主键 3.表没有主键 ,INNODB 会默认设置隐藏的主键列 ;没有主键的表在定位数据行的时候非常困难 ,也会降 低基于行复制的效率。 范式 1.表不要求一定满足第三范式，根据实际情况可适当添加冗余字段。 2.我们的原则是一个 SQL 最好只操作一个表，最多不能超过 3 个表的关联。如果实现一个常用的功 能需要一个关联多表的查询，则需要重新考虑设计。 3. 由程序保证冗余数据的维护。 . . 约束 1.对于字典类型的表，因数据量小，修改少，影响面大，应依赖数据库约束来确保数据质量。 2.对于日志或流水型表，为了提升效率，可以释放放宽限制。 之所以分开，是从性能以及影响面考虑的。 对于字典类型的数据，因为修改少，约束给其性能带来的负面影响忽略。但是一个数据字段的数据错 误，影响面非常广，因此，需要非常严谨。前段程序或者手工添加此类数据时，容易出现错误，因此 需要通过约束来保证其数据的质量。 日志或者流水型表刚好相反，它一般只影响个别用户，但数据量较大，修改较为频繁，性能优先。 字段 1.对于字段设计，概况下来一个原则是：越简单越好，越小越好。 2. 选择最合适的数据类型，能用数字类型不用 varchar 类型；能用 date/datetime 类型不用 varchar 类型；避免使用 char 类型；不使用浮点数，可以通过乘以一个系数来转换为整型数据。 3. 字段长度定义遵循最小化原则，够用就行，不能贪图方便定义很大的长度。 过大的长度容错性高，容易出现低质量数据。 4.一个表的字段个数控制在 30-50 个字段以内； 如果字段超过 50 个，可考虑将字段按冷热程度分表。 这样做虽然会给应用带来更多的代码开发量，但对于热表来说，这样做可以提升 buffer 利用率，减少 IO，提升查询的效率。 每一个重要的业务表都加上 create_time 和 isDel 两个字段，数据类型为 datetime 和 integer ； 索引 /主键设计 1.主键由一个字段构成，最多不要超过 3 个，禁止超过 3 个字段的组合主键。如果业务要求，则创建 一个自增字段作为主键，再添加一个唯一索引。 如果查询都是基于主键字段，且只有 1 个及以下辅助索引，则限制可以放宽。 . . 在建表时，应充分考虑需要添加什么索引，尽量避免上线后添加索引 其它 为方便后续的维护和开发，建表设计时必须详细注释表名，字段名用途。 .