IDC表设计规范说明_第1页
IDC表设计规范说明_第2页
IDC表设计规范说明_第3页
全文预览已结束

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

1、.数据库表设计规范目的为了规范数据库设计，减少设计失误，提高数据安全及性能，特制订本规范。适用范围适用本系统 MySQL数据库。原则上，数据库设计应遵循本规范说明，特殊情况可例外，但需说明原因。规范命名1.库名、表名、字段名必须使用小写字母,命名有需要的话采用下划线分割2.库名、表名、字段名禁止超过32个字符3.库名、表名、字段名支持最多64个字符 ,但为了统一规范、易于辨识以及减少传输量,禁止超过 32个字符。4.库名、表名、字段名禁止使用MySQL 保留字表1.减少或避免使用临时表；2.每一个表都需要设置主键3.表没有主键 ,INNODB 会默认设置隐藏的主键列;没有主键的表在定位数据行的

2、时候非常困难,也会降低基于行复制的效率。范式1.表不要求一定满足第三范式，根据实际情况可适当添加冗余字段。2.我们的原则是一个SQL 最好只操作一个表，最多不能超过3 个表的关联。如果实现一个常用的功能需要一个关联多表的查询，则需要重新考虑设计。3.由程序保证冗余数据的维护。'.约束1.对于字典类型的表，因数据量小，修改少，影响面大，应依赖数据库约束来确保数据质量。2.对于日志或流水型表，为了提升效率，可以释放放宽限制。之所以分开，是从性能以及影响面考虑的。对于字典类型的数据，因为修改少，约束给其性能带来的负面影响忽略。但是一个数据字段的数据错误，影响面非常广，因此，需要非常严谨。前段

3、程序或者手工添加此类数据时，容易出现错误，因此需要通过约束来保证其数据的质量。日志或者流水型表刚好相反，它一般只影响个别用户，但数据量较大，修改较为频繁，性能优先。字段1.对于字段设计，概况下来一个原则是：越简单越好，越小越好。2. 选择最合适的数据类型，能用数字类型不用varchar 类型；能用 date/datetime 类型不用 varchar类型；避免使用char 类型；不使用浮点数，可以通过乘以一个系数来转换为整型数据。3. 字段长度定义遵循最小化原则，够用就行，不能贪图方便定义很大的长度。过大的长度容错性高，容易出现低质量数据。4.一个表的字段个数控制在30-50 个字段以内；如果字段超过50 个，可考虑将字段按冷热程度分表。这样做虽然会给应用带来更多的代码开发量，但对于热表来说，这样做可以提升buffer 利用率，减少IO，提升查询的效率。每一个重要的业务表都加上create_time和 isDel 两个字段，数据类型为datetime 和 integer ；索引 /主键设计1.主键由一个字段构成，最多不要超过 3 个，禁止超过 3 个字段的组合主键。如果业务要求，则创建一个自增字段作为主键，再添加一个唯一索引。如果查询都是基于主键字段，且只有1 个及以下辅助索引，则限制可以放宽。'.在建表时，应充分考

人人文库> 全部分类> 行业资料 > 信息产业

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论