IDC表设计规范说明
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据库表设计规范
目的
为了规范数据库设计,减少设计失误,提高数据安全及性能,特制订本规范。
适用范围
适用本系统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个及以下辅助索引,则限制可以放宽。
在建表时,应充分考虑需要添加什么索引,尽量避免上线后添加索引
其它
为方便后续的维护和开发,建表设计时必须详细注释表名,字段名用途。