header-bg.jpg
MySQL 开发规范
发表于 2019-07-04 08:57
|
分类于 MySQL
|
评论次数 0
|
阅读次数 281

编码规范对于程序员而言尤为重要,一个软件的生命周期中,80%的花费在于维护,并且几乎没有任何一个软件,在其整个生命周期中,均由最初的开发人员来维护。

遵循一套编码规范可以改善软件的可读性,可以让程序员尽快而彻底地理解新的代码,如果你将源码作为产品发布,就需要确任它是否被很好的打包并且清晰无误,一如你已构建的其它任何产品。

同样的, MySQL 开发也需要一套规范,所以本文记录一下适用于大众的 MySQL 开发规范,我也确信这套开发规范不会适用于所有的开发团队,所以根据过去的经验、周围的技术栈、个人价值观做出有意义的偏差是可取的。

命名规范

关于表名有一个有趣的问题:表名应该使用单数还是复数,例如一个用户表,表名是用 user 还是 users 更合适呢?

这是一个很古老的问题,并且在 Stackoverflow 上有很大的争议,比较高票的回答是建议使用单数

stackoverflow 原文链接

而 PHP 的 Laravel 框架推荐是使用复数形式,若没有特别指定,laravel 会默认自动对应名称为「Eloquent 类名称的小写复数形式」的数据库表。

虽然我也使用 Laravel 框架,但是我还是喜欢单数形式,Stackoverflow 上的大佬建议使用单数的理由是:

(1)概念直观。
你有一个袋子,里面有好多个苹果,你会说这是个苹果袋。但无论里面有0,1,百万个苹果,它依然是个袋子。表也是如此,表明需要描述清楚,表里面包含的对象,而非有多少个数据。

(2)便利性
单数形式更简单。有一些单词,它的复数形式可能是非常规的,或者就没有复数形式,但是单数不一样,单数形式则没那么多讲究。有些单词的复数,可能会想到你头大,可能得好好google才出来

(3)优雅
特别是一些master-detail形式的资源名称,统一用单数,读起来更方便,对齐更整齐,从顺序上更有逻辑性。
对比下
单数:
Order
OrderDetail
复数:
OrderDetails
Orders

(4)简单朴素
设想下,不管是表名,主键,关系,实例Classes,你都可以统一用单数,所有看上去那么统一,也不用费心地各种复数单数中转换你的思维
Customer
Customer.CustomerID
CustomerAddress
public Class Customer {…}
SELECT FROM Customer WHERE CustomerID = 100
一旦你确定,要处理的这个对象,名字定为Customer,那么所有和数据库相关的交互、编程就都将使用这个单词

(5)全球化
假设你身处一个全球化的团队,成员中有些人,母语不是英文,对他们来说,辨认、书写一个单词的复数形式,要更困难,会给他们带来麻烦,也给团队合作带来麻烦。

(6)为什么不
这可以节省你的拼写时间,硬盘空间,甚至让你的键盘更“长寿”

看完我都惊了,真是让人无力反驳,所以我也建议大家都使用单数就好了嗷~

papa.gif

基础规范

表库设计

字段设计

索引规范

MySQL 查询优化说起来非常复杂,不是一句两句能讲清的,这里只提供一些规范建议,不做过多说明。

索引的用途

索引数量控制

主键准则

重要的 SQL 必须被索引

UPDATE、DELETE 语句的 WHERE 条件列
ORDER BY、GROUP BY、DISTINCT 的字段
多表 JOIN 的字段

索引禁忌

外键⽤来保护参照完整性,可在业务端实现
对父表和子表的操作会相互影响,降低可用性
INNODB 本身对 online DDL 的限制

⽆法使⽤索引,导致全表扫描,全表扫描导致bufer pool利⽤率降低

发布评论
还没有评论,快来抢沙发吧!