数据库设计约定.pdf

数据库设计约定 ⼀、公共部分 ⼀、公共部分 1、存储引擎 、存储引擎 默认Innodb，⾮特殊要求⼀律使⽤此引擎 2、字符集 、字符集 Database Server 字符集统⼀默认UTF-8，table和column从server继承 ⼆、表设计约定 ⼆、表设计约定 1、主键 、主键 每张表必须包含物理⾃增主键，如主键字段不能满⾜业务需求，另建unique约束业务字段 2、外键 、外键 数据库表禁⽌主外键关联，需要在程序业务逻辑中维护。特殊情况如跟⽀付，财务模块相关，⽅可考虑主外键 3、表名，字段，索引命名规则 、表名，字段，索引命名规则 TABLE: 同⼀业务模块使⽤相同表前缀，如tb_pay_xxxx,字典表⽤dim_xxxx Column: XXXX_XXXX，中间以下划线隔开 4、公共字段 、公共字段 每张表包含2个公共字段，created_at，updated_at is_delete作为标识记录逻辑删除，⾮必须字段，枚举类型(tinyint(4))，0有效，1删除，默认为0（有效），如数据量增长过⼤可通过 归档，归档后在表中物理删除。 created_at,updated_at 字段作为DT增量拉取数据和数据回退等场景下使⽤，created_at 默认current_timestamp updated_at 默认current_timestamp，on update current_timestamp 5、字段冗余 、字段冗余 ⾮严格遵守3NF，通过业务字段冗余来减少表关联 6、字段类型长度选择 、字段类型长度选择 主键字段：bigint(20),int(11) 根据预估数据量选择，如果选择int(11)需要标注为unsigned 字符串：尽可能使⽤定长char类型，如姓名，⾝份证号码，如需要变长varchar，尽可能根据实际情况限制长度，如description等 枚举类型：统⼀tinyint(4)，只占⼀个字节 ⽇期：date,datetime, timestamp，根据实际情况选择 ⾦额：使⽤decimel(xx,2) 7、字段不允许为空 、字段不允许为空 不允许可为空字段，必须有默认值 时间字段默认值建议： 1）date类型,默认值⾮current_date()下，默认值为'1970-01-01' 2）datetime类型，默认值⾮current_timestamp()下，设置为'1970-01-01 08:00:01' 3）timestamp类型，默认值⾮current_timestamp()下，设置成'1970-01-01 08:00:01' 8、注释 、注释 建表包含表注释，尤其枚举类型需要说明每⼀种含义 9、⼤字段 、⼤字段(text/blob) 原则上不允许这种字段，尽可能的拆分成⼩字段，如果特别需要，⽽⼜读写频繁，另外建⼀张表 三、索引约定 三、索引约定 1、命名 、命名 主键：pk_columnName (或者让数据库⾃动命名); 唯⼀键：uk_columnName; 普通索引：ix_columnName; 组合索引ix_column1_column2_column3; 如长度太长则截取部分，取义直观 2、必须包含索引 、必须包含索引 公共字段created_at和updated_at必须建⽴索引 军规适⽤场景：并发量⼤、数据量⼤的互联⽹业务 ⼀、基础规范 （1）必须使⽤InnoDB存储引擎 解读：⽀持事务、⾏级锁、并发性能更好、CPU及内存缓存页优化使得资源利⽤率更⾼ （2）必须使⽤UTF8字符集 解读：万国码，⽆需转码，⽆乱码风险，节省空间 （3）数据表、数据字段必须加⼊中⽂注释 解读：N年后谁tm知道这个r1,r2,r3字段是⼲嘛的 （4）禁⽌使⽤存储过程、视图、触发器、Event 解读：⾼并发⼤数据的互联⽹业务，架构设计思路是"解放数据库CPU，将计算转移到服务层"，并发量⼤的情况下，这些功能很可能将数 据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现"增机器就加性能"。数据库擅长存储与索引，CPU计算还是上移吧 （5）禁⽌存储⼤⽂件或者⼤照⽚ 解读：为何要让数据库做它不擅长的事情？⼤⽂件和照⽚存储在⽂件系统，数据库⾥存URI多好 ⼆、命名规范 （6）库名、表名、字段名：⼩写，下划线风格，不超过32个字符，必须见名知意，禁⽌拼⾳英⽂混⽤ （7）表名t_xxx，⾮唯⼀索引名idx_xxx，唯⼀索引名uniq_xxx 三、表设计规范 （8）单实例表数⽬必须⼩于500 （9）单表列数⽬必须⼩于30 （10）表必须有主键，例如⾃增主键 解读： a）主键递增，数据⾏写⼊可以提⾼插⼊性能，可以避免page分裂，减少表碎⽚提升空间和内存的使⽤ b）主键要选择较短的数据类型， Innodb