Alibaba数据库设计规范
-
【强制】表达是与否概念的字段,必须使用
is_xxx
的方式命名,数据类型是unsigned
tinyint
(1
表示是,0
表示否)。- 说明:任何字段如果为非负数,必须是
unsigned
。 - 正例:表达逻辑删除的字段名
is_deleted
,1
表示删除,0
表示未删除。
- 说明:任何字段如果为非负数,必须是
-
【强制】表名、字段名必须使用小写字母或数字,禁止出现数字开头,禁止两个下划线中间只出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。
- 说明:
MySQL
在Windows
下不区分大小写,但在Linux
下默认是区分大小写。因此,数据库名、表名、字段名,都不允许出现任何大写字母,避免节外生枝。 - 正例:
aliyun_admin
,rdc_config
,level3_name
- 反例:
AliyunAdmin
,rdcConfig
,level_3_name
- 说明:
-
【强制】表名不使用复数名词。
- 说明:表名应该仅仅表示表里面的实体内容,不应该表示实体数量,对应于DO类名也是单数形式,符合表达习惯。
-
【强制】禁用保留字,如
desc
、range
、match
、delayed
等,请参考MySQL
官方保留字。 -
【强制】主键索引名为
pk_
_字段名;唯一索引名为uk_
字段名;普通索引名则为idx_
字段名- 说明:
pk_
即primary key
;uk_
即unique key
;idx_
即index
的简称。
- 说明:
-
【强制】小数类型为
decimal
,禁止使用float
和double
。- 说明:
float
和double
在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不正确的结果。如果存储的数据范围超过decimal
的范围,建议将数据拆成整数和小数分开存储。
- 说明:
-
【强制】
varchar
是可变长字符串,不预先分配存储空间,长度不要超过5000
,如果存储长度大于此值,定义字段类型为text
,独立出来一张表,用主键来对应,避免影响其它字段索引效率。 -
【强制】表必备三字段:
id
,gmt_create
,gmt_modified
。- 说明:其中
id
必为主键,类型为unsigned
bigint
、单表时自增、步长为1
。gmt_create
,gmt_modified
的类型均为datetime
类型,前者现在时表示主动创建,后者过去分词表示被动更新。
- 说明:其中
-
【推荐】表的命名最好是加上“业务名称_表的作用”。
- 正例:
alipay_task
/force_project
/trade_config
- 正例:
-
【推荐】库名与应用名称尽量一致。
-
【推荐】如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。
-
【推荐】字段允许适当冗余,以提高查询性能,但必须考虑数据一致。冗余字段应遵循:
- (1) 不是频繁修改的字段。
- (2) 不是
varchar
超长字段,更不能是text
字段。正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存储类目名称,避免关联查询。
-
【推荐】单表行数超过
500
万行或者单表容量超过2GB
,才推荐进行分库分表。- 说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。
-
【参考】合适的字符存储长度,不但节约数据库表空间、节约索引存储,更重要的是提升检索速度。
- 正例:如下表,其中无符号值可以避免误存负数,且扩大了表示范围。
对象 | 年龄区间 | 类型 | 字节 | 表示范围 |
---|---|---|---|---|
人 | 150 岁以内 | unsigned tinyint | 1 | 无符号值:0~255 |
乌龟 | 数百岁 | unsigned``smallint | 2 | 无符号值:0~65535 |
恐龙化石 | 数千万年 | unsigned int | 4 | 无符号值:0~42.9 亿 |
太阳 | 约50亿年 | unsigned bigint | 8 | 无符号值:0~10 的19 次方 |
其他设计思路
- 关于
varchar
的长度- 关于
varchar
的长度,一般只需要大概设计,而不会设计得非常具体,更加不会设计得“刚刚好” 。 - 以“用户名”为例,当前项目的业务规则可能是“长度必须
4~8
字符”,但是,以后出现新的需求时,可能将规则改为“长度必须6~12
字符”,如果一开始设计为varchar(8)
则需要改为varchar(12)
,而且,随着项目的继续运营,业务规则仍可能再次改变! - 数据库只是用于读写数据的载体,不应该体现业务规则,而且,调整数据库(或数据表)设计的风险太大,所以,一般把
varchar
的长度设计为“肯定满足当前业务规则,并且,即使以后调整业务规则,当前设计也是满足的” ,简单来说, “设计为充裕的长度”。 - 当然,也不要设计得特别大,以
utf8mb4
编码为例,理论的最大长度是16383
,那么,把所有的varchar
长度都设置为非常大的值(与表的字段数量也有关系,不可以多个varchar
字段的长度都设置为16383
)是不会出错的,但是,特别大的值可能会导致一些歧义,例如把“用户名”的长度设置为500
是不合适的,因为,无论业务规则怎么调整,都不会出现长达500
长度的用户名。 - 大概划分了几个档次的长度,例如
50、255、2500
等(你也可以自行添加更多档次),较短的字段使用varchar(50)
,例如“用户名” 、 “昵称” ,略长的使用varchar(255)
,例如“商品标题”、“商品关键词”等,更长的且不足以使用text
的就使用varchar(2500)
,例如“商品的规格参数集合”等. - 总的来说,数据表的设计不会精准对应业务规则(例如用户名长度最多
12
字符),业务规则应该通过程序来实现。
- 关于
- 关于
not null
的约定- 关于
not null
,一般不推荐设置,使用default null
(或不设置,亦等效)即可。 - 这样的设计思路与以上
varchar
的长度也大致相同:很难确定以后是否会出现新的运营模式或业务规则. - 例如在早期, “用户”的“用户名”和“密码”就是必要的数据,设计为
not null
非常合理,但是,随着手机的普及,现在许多平台都可以使用“手机号码”和“手机验证码”实现登录,根本不需要“用户名”和“密码” ,在这种情景下, “用户名”和“密码”就需要设计为“允许为null
” 。 - 另外,因为思维模式的局限性,站在开发人员的角度,可能很难想像某些数据“允许为
null
”的情景,例如“商品”的“价格”,但是,结合界面的设计、使用者的操作习惯,not null
的约束可能会带来一些问题,例如,当商家准备发布一款商品时,可能“价格”还没有最终确定,但是希望先填写其它信息,例如商品的“标题” 、“简介”、“详细介绍”等,如果把“价格”设计为not null
,使用者的操作就非常不灵活,所以,“允许为null
”会让设计变得更加自由。 - 其实,数据是否允许为
null
,在某种程度上来说,也算是一种业务规则(是否必须填写),只要程序的业务逻辑是完整的,在数据库(或数据表)中并不需要设计得特别严格,还是那句话,调整数据库(或数据表)设计的风险太大,能够通过程序完善的,就不要在数据库(或数据表)中设计规则。
- 关于
- 关于
unique
约束- 该约束表示“唯一” ,以“用户”为例,如果需要“用户名”具有“唯一”的特性,则可以添加
unique
。 - 但是,此前的设计思路中一直有个观点:业务规则应该通过程序来实现。所以,如果要保证“唯一”的特性,只要程序的业务逻辑是完整的,根本不需要在表中添加
unique
约束!同时,通过数据表的设计来添加约束反而会使用得程序设计受到约束,后期还可能带来维护相关问题!这样看来,添加unique
约束可能不是什么好事。 - 其实,设计数据表时添加的
unique
约束可以作为数据安全的最后一道防线,即使出现某些特殊的情况导致程序业务逻辑出现Bug
,甚至某些数据绕过程序代码直接发送到了数据库服务器,也能保证数据是“唯一的”,不过,这不是最主要的原因,unique
不仅仅只是一种约束,它还是一种索引(唯一索引),能非常明显的提高该字段的查询效率,以“用户”为例,绝大部分项目的期望用户数量都是达到千万级甚至更多,在验证用户身份(例如:登录)时可能需要“根据用户名查询数据”,如果没有索引,查询效率就会非常低,有索引时查询效率就非常高!综合来看,“用户名”这样的字段,既需要是“唯一的” ,也需要保证该字段的查询效率,那么,使用unique
是一举两得的。
- 该约束表示“唯一” ,以“用户”为例,如果需要“用户名”具有“唯一”的特性,则可以添加