拓展阅读

MySQL Ruler

写在前面:

一、为何写

为了自己以后的脚本编写或者是为团队公司提供一个可以达成共识的标准。

二、怎么定规范

简洁明了。根据实际业务可以进行调整。每一个规定尽量描述清楚缘由。规范必须是不断变化的,量体裁衣。

三、参考

《架构师之路》中有提及一些数据库军规。可以提供参考。

四、使用

解读比规则本身更重要。

规范草案

基础规范

适用于所有。(database, table, column)

1、必须有中文解释

可以解释到任何一个程序员(包括黑客)看到注释后立刻理解其中的含义。而不是推敲其中的意思。为了保证这一点,衍生了第二条。

2、尽量使用英文,禁止中英文混用命名。

比如你看到了 zhrmghg 这个字段然后觉得很深奥,后来问命名者告诉你是中华人民共和国的简拼啊,你看不出来啊。。。

3、命名禁止出现大写字母, 禁止出现_以外的字符。

必须保证命名规则转换后可以符合比如驼峰命名。

4、禁止使用数字。使用英文单词替代。

举个例子 email_1 , 那么请重命名为email_one。相信你可写出0-99的英文单词。避免,分不清l1, 分不清o0。

5、禁止使用双引号对名称引用, 避免大小写敏感。

如果需要单词间空格, 替换为下划线。

6、所有的命名尽量指出字段的业务含义。

如此之难,以至于想将这一条删除。

数据库规范

1、统一使用 UTF-8 编码

无需转码,无乱码风险。

2、数据库命名与系统名称保持一致。且必须满足基础规范。

比如项目名称blog-service , 对应数据库名称 blog_service

表规范

1、如果是 MySQL, 请使用 InnoDB 引擎

支持事务。其他不吹不黑。

2、必须有主键。

如BIGINT(20)自增的ID, 有利于表的管理。但是这个ID未必是你的唯一约束主键。

3、禁止使用外键。

所有的关联使用应用程序去保证。

4、表名称应统一使用t_开头。

可以与普通的类区分开。当然这一点不强求。(很多公司做不到)

列规范

1、禁止列名使用 col等毫无意义的作为前缀/后缀。

不要把名称浪费在无用的事情上。

2、主键命名统一为id, 当然你也可以使其不包含任何业务含义。

不多说。

3、表中一般会包含2个字段,创建时间和更新时间。请自行统一约定。

date 一般指日期, time 指时间。你可以约定为 created_time 和 updated_time。保证所有的表统一。不要乱改名字。

4、所有的字段都尽量设定为 NOT NULL

这一点根据业务而定。其实 null 不节约任何空间且会导致查询性能优化变得困难。

5、禁止使用 TEXT、BLOB 此类较大的字段

存放他的URL,对应的内容放在文件服务器中。

索引规范

1、单表索引不易过多。(5个以内为佳)

2、组合索引,区分度大的放在前面。

利于数据的快速过滤。

3、索引命名如下:

pk 主键 (primary key)
uk 唯一键 (unique key)
nk 普通索引 (normal key)

以上命名方式为前缀。你会说为什么不写英文全拼啊 ? 不现实,总会有人写错。

SQL 使用规范

1、禁止使用 SELECT *, 必须指定需要查询的字段。

2、禁止使用 INSERT INTO t_xxx VALUES (XXX), 必须明确指定插入的列属性

3、禁止全表扫描

可以看下索引不工作的case, 实在无法避免可以和前端结合。比如查询必须指定某一区分度很大的字段才能查询。

4、尽量不使用 JOIN

这一点很多人难以接受。处于性能无可厚非的规则。但是如果性能要求没有这么高,资源又有限,可不必遵循。

MySQL Ruler mysql 日常开发规范

拓展阅读

MySQL Ruler

规范草案

SQL 使用规范