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，才推荐进行分库分表。

  • 说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

• 【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。

  • 正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。

其他设计思路

1. 关于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字符），业务规则应该通过程序来实现。
2. 关于not null的约定
   • 关于not null，一般不推荐设置，使用default null（或不设置，亦等效）即可。
   • 这样的设计思路与以上varchar的长度也大致相同：很难确定以后是否会出现新的运营模式或业务规则.
   • 例如在早期， “用户”的“用户名”和“密码”就是必要的数据，设计为not null非常合理，但是，随着手机的普及，现在许多平台都可以使用“手机号码”和“手机验证码”实现登录，根本不需要“用户名”和“密码” ，在这种情景下， “用户名”和“密码”就需要设计为“允许为null” 。
   • 另外，因为思维模式的局限性，站在开发人员的角度，可能很难想像某些数据“允许为null”的情景，例如“商品”的“价格”，但是，结合界面的设计、使用者的操作习惯，not null的约束可能会带来一些问题，例如，当商家准备发布一款商品时，可能“价格”还没有最终确定，但是希望先填写其它信息，例如商品的“标题” 、“简介”、“详细介绍”等，如果把“价格”设计为not null，使用者的操作就非常不灵活，所以，“允许为null”会让设计变得更加自由。
   • 其实，数据是否允许为null，在某种程度上来说，也算是一种业务规则（是否必须填写），只要程序的业务逻辑是完整的，在数据库（或数据表）中并不需要设计得特别严格，还是那句话，调整数据库（或数据表）设计的风险太大，能够通过程序完善的，就不要在数据库（或数据表）中设计规则。
3. 关于unique约束
   • 该约束表示“唯一” ，以“用户”为例，如果需要“用户名”具有“唯一”的特性，则可以添加unique。
   • 但是，此前的设计思路中一直有个观点：业务规则应该通过程序来实现。所以，如果要保证“唯一”的特性，只要程序的业务逻辑是完整的，根本不需要在表中添加unique约束！同时，通过数据表的设计来添加约束反而会使用得程序设计受到约束，后期还可能带来维护相关问题！这样看来，添加unique约束可能不是什么好事。
   • 其实，设计数据表时添加的unique约束可以作为数据安全的最后一道防线，即使出现某些特殊的情况导致程序业务逻辑出现Bug，甚至某些数据绕过程序代码直接发送到了数据库服务器，也能保证数据是“唯一的”，不过，这不是最主要的原因，unique不仅仅只是一种约束，它还是一种索引（唯一索引），能非常明显的提高该字段的查询效率，以“用户”为例，绝大部分项目的期望用户数量都是达到千万级甚至更多，在验证用户身份（例如：登录）时可能需要“根据用户名查询数据”，如果没有索引，查询效率就会非常低，有索引时查询效率就非常高！综合来看，“用户名”这样的字段，既需要是“唯一的” ，也需要保证该字段的查询效率，那么，使用unique是一举两得的。