代码编织梦想

Alibaba数据库设计规范

  • 【强制】表达是与否概念的字段,必须使用is_xxx的方式命名,数据类型是unsigned tinyint (1表示是,0表示否)。

    • 说明:任何字段如果为非负数,必须是unsigned
    • 正例:表达逻辑删除的字段名is_deleted1表示删除,0表示未删除。
  • 【强制】表名、字段名必须使用小写字母或数字,禁止出现数字开头,禁止两个下划线中间只出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。

    • 说明:MySQLWindows下不区分大小写,但在Linux下默认是区分大小写。因此,数据库名、表名、字段名,都不允许出现任何大写字母,避免节外生枝。
    • 正例:aliyun_adminrdc_configlevel3_name
    • 反例:AliyunAdminrdcConfiglevel_3_name
  • 【强制】表名不使用复数名词。

    • 说明:表名应该仅仅表示表里面的实体内容,不应该表示实体数量,对应于DO类名也是单数形式,符合表达习惯。
  • 【强制】禁用保留字,如descrangematchdelayed等,请参考MySQL 官方保留字。

  • 【强制】主键索引名为pk__字段名;唯一索引名为uk_字段名;普通索引名则为 idx_字段名

    • 说明:pk_primary keyuk_unique keyidx_index的简称。
  • 【强制】小数类型为decimal,禁止使用floatdouble

    • 说明:floatdouble在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不正确的结果。如果存储的数据范围超过decimal的范围,建议将数据拆成整数和小数分开存储。
  • 【强制】varchar是可变长字符串,不预先分配存储空间,长度不要超过5000,如果存储长度大于此值,定义字段类型为text,独立出来一张表,用主键来对应,避免影响其它字段索引效率。

  • 【强制】表必备三字段:idgmt_creategmt_modified

    • 说明:其中id必为主键,类型为unsigned bigint、单表时自增、步长为1gmt_creategmt_modified的类型均为datetime类型,前者现在时表示主动创建,后者过去分词表示被动更新。
  • 【推荐】表的命名最好是加上“业务名称_表的作用”。

    • 正例:alipay_task / force_project / trade_config
  • 【推荐】库名与应用名称尽量一致。

  • 【推荐】如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。

  • 【推荐】字段允许适当冗余,以提高查询性能,但必须考虑数据一致。冗余字段应遵循:

    • (1) 不是频繁修改的字段。
    • (2) 不是varchar超长字段,更不能是text字段。正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存储类目名称,避免关联查询。
  • 【推荐】单表行数超过 500 万行或者单表容量超过2GB,才推荐进行分库分表。

    • 说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。
  • 【参考】合适的字符存储长度,不但节约数据库表空间、节约索引存储,更重要的是提升检索速度。

    • 正例:如下表,其中无符号值可以避免误存负数,且扩大了表示范围。
对象年龄区间类型字节表示范围
150岁以内unsigned tinyint1无符号值:0~255
乌龟数百岁unsigned``smallint2无符号值:0~65535
恐龙化石数千万年unsigned int4无符号值:0~42.9亿
太阳约50亿年unsigned bigint8无符号值:0~1019次方

其他设计思路

  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是一举两得的。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/syt_Q/article/details/127002581

数据库设计——由阿里的java编程规范引发的外键思考_山月风成的博客-爱代码爱编程

1 阿里的Java编程规范 【强制】不得使用外键与级联,一切外键概念必须在应用层解决。 说明:以学生和成绩的关系为例,学生表中的student_id是主键,那么成绩表中的student_id则为外键。如果更新学生表中的s

阿里巴巴 Alibaba Java开发规范 总结版 快速阅读版-爱代码爱编程

命名规范及变量定义 类名:UpperCamelCase方法,参数,局部变量,成员变量:lowerCamelCase常量:全部大写,下划线隔开单词抽象类:以Abstract或者Base开头异常类:以Exception结尾测试类:以Test结尾POJO类中布尔类型的变量:不要加is,部分框架解析会引起序列化的错误包名:全部小写,点分隔单词缩写:尽量不要,名字

数据库设计范式-爱代码爱编程

数据库规范化,又称正规化、标准化,是数据库设计的一系列原理和技术,以减少数据库中数据冗余,增进数据的一致性。关系模型的发明者埃德加·科德最早提出这一概念,并于1970年代初定义了第一范式、第二范式和第三范式的概念,还与Raymond F. Boyce于1974年共同定义了第三范式的改进范式——BC范式。 除外还包括针对多值依赖的第四范式,

IDEA 代码质量插件 Alibaba代码规范 和 SonarLint-爱代码爱编程

代码质量的重要性 在我们日常完成需求中,常常因为时间紧迫,项目紧急上线,总想着先实现再说,然后等日后上线之后再慢慢优化,我相信,你可能看过很多祖传代码,各种//TODO,然而往往随着项目的上线,TODO就变成DONE了。 其实,不是我们不想去完成TODO,而是一旦项目上线交付,验证过后的功能再次修改肯定会带来一定的风险,所以只要不出问题,就不会再次打开

阿里——数据库设计规范(转自阿里平台,仅学习使用)-爱代码爱编程

阿里——数据库设计规范(转自阿里平台,仅学习使用) 基于阿里数据库设计规范扩展而来 设计规范 1.【推荐】字段允许适当冗余,以提高查询性能,但必须考虑数据一致。冗余字段应遵循: 不是频繁修改的字段。 不是 varchar 超长字段,更不能是 text 字段。 正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存 储类

阿里mysql命名规范_MySQL命名、设计及使用规范《MySQL命名、设计及使用规范》-爱代码爱编程

数据库环境 dev:开发环境,开发可读写,可修改表结构。开发人员可以修改表结构,可以随意修改其中的数据但是需要保证不影响其他开发同事。 qa:测试环境,开发可读写,开发人员可以通过工具修改表结构。 sim:模拟环境,开发可读写,发起上线请求时,会先在这个环境上进行预执行,这个环境也可供部署上线演练或压力测试使用。 real:生产数据库从库(准实

Api接口设计规范-爱代码爱编程

接口设计:   一 安全性问题 安全性问题是一个接口必须要保证的规范。如果接口保证不了安全性,那么你的接口相当于直接暴露在公网环境中任人蹂躏。 1.1 调用接口的先决条件-token token,使用参数client_id,timestamp,client_sercet,state来获取token,作为系统调用的唯一凭证。token可以设置一

【SpringCloud Alibaba】08--单点系统结合数据库和Feign-爱代码爱编程

一,业务描述 1.增加数据库访问 第一:登录用户信息来自数据库(用户自身信息以及用户对应的权限信息) 第二:将上传的文件信息写入到数据库 第三:将登录操作,文件上传操作的操作日志写入到数据库. 2.增加服务之间的调用 第一:认证服务调用系统服务(获取用户以及用户权限) 第二:认证服务与资源服务都调用系统服务(将日志传递给系统服务,进行数据的持久化)

mysql数据库实战规范-爱代码爱编程

9、禁止使用预留字段 很多小伙伴为了以后的业务扩展,都喜欢在表中建立类似DEMO_1、DEMO_2字段,列名没有任何业务含义,而且类型都是用String代替。 预留字段另一个好处就是业务改变后,利用预留字段,SQL语句不需要改变,其实这个问题用一些ORM工具就能够很好的解决 字段设计规范 1、优先选择符合业务的最小存储类型 可以有效

数据库连接池-爱代码爱编程

目录 简介 连接池原理 数据库连接池 C3P0 Proxool Jakarta DBCP DDConnectionBroker DBPool XAPool Primrose SmartPool MiniConnectionPoolManager BoneCP Druid 简介 数据库连接池负责分配、管理和释放数据

java连接数据库规范——jdbc_鑫仔的记忆的博客-爱代码爱编程

文章目录 一、引言1.1 如何操作数据库1.2 实际开发中,会采用客户端操作数据库吗?二、JDBC(Java Database Connectivity)2.1 什么是 JDBC?2.2 JDBC 核心思想2.2.1 MySQL 数据库驱动2.2.2 JDBC API2.3 环境搭建三、JDBC 开发步骤【`重点`】3.1 注册驱动3.2 连接数据

springboot的数据库连接池_springboot数据库连接池-爱代码爱编程

一、前言 开发web项目,我们肯定会和数据库打交道,因此就会涉及到数据库链接的问题。在以前我们开发传统的SSM结构的项目时进行数据库链接都是通过JDBC进行数据链接,我们每和数据库打一次交道都需要先获取一次链接,操作完后再