DBA成长之路-数据库设计避坑之路最后
写在前面
最新更新： 2023--07-17
更新内容：新增索引设计
笔者最近正在享受成为一名DBA带来的快感, 同时总结一些自己在设计过程中的理念和一些避坑指南,适用于对数据库有一定了解和应用的童鞋
注: 以下提到的数字均来自笔者多次参与数据库的设计经验，哦对了是从阿里巴巴数据库开发规范中一些
数据库设计过程
作为一名DBA 必要的理论基础必不可少, 也就说在我们准备设计数据库时,有些理论是必须掌握的, 相信已经有不少童鞋已经学过或者看过6大设计步骤, 我以具体实际过程阐述这前5个步骤 (第6个步骤笔者需要一个时间累积,方能给出结果)
理论上DB设计过程:
【持续更新【筑基之石】DBA成长之路-数据库设计避坑之路】物理结构设计-避坑指南 字段设计 未雨绸缪 如果你需求分析阶段准备的很充足 那这一部分就像是一个中英互译的过程, 但是一旦有纰漏 那么它就像一颗定时炸弹
笔者曾经就因为出现对某个表的设计不够充分, 匆忙开发 结果开发到一半时 猛然发现需要补充一个字段, 有些朋友应该能体会其中的恐怖之处, 返工是开发过程中最忌讳, 最要命的
解决思路是: 如果你能确定某个实体的所有属性 那么放心设计就好, 如果但凡你有一点不确定的地方那么 你至少要准备一个扩展字段以备不时之需(自信是程序员的必修课哈哈哈哈)
必须字段 其实有时候设计表设计多了 你会发现 总会有这么几个字段都是通用的: id, , , , , 不过有时候也很苦恼 无论你维护几个字段都需要这5个字段去协助, DBA也很苦呀…尽可能使用编码格式为, 怎么说呢, 其实也是未雨绸缪, 因为现在有些场景会用到emoji表情
笔者曾经写cms 时候用到过emoji 当时设计的是utf8编码 导致sql解析出错, 忙活了好一阵子,原因在于emoji 是占用四个字节的
文章插图
平常使用uf8是占用1-3个字节, 芳名 而是它的超集 支持1-4字节 所以能够有效解决表情存储问题,
给 和_time添加默认值
这个是笔者苦逼的开发经历总结得出, CRUD的业务有时候需要记录操作的时间, 之前没有注意Mysql的默认值, 自己徒手更新时间 有时候还经常忘记, 痛苦好一阵子
首先这两个字段的存在意义你会下面看到, 另外他们都是类型有了这个前提, 我们再说具体设置最好设置成:设计成NULL ON有了这两个默认值 开发直接起飞, 完全不需要我们去考虑维护, mysql自动更新 非常实用!!!
按需设计，切勿过多考虑，无论是数值类还是字符类字段，在合理预估范围内，最多2倍大小足矣，比如你的地址，撑死也就100来个字符，256足够，再比如你的状态撑死也就十几个，也完全够了 。
字段命名
看似好像是英文互译, 但是也有些需要注意的地方
数据库名 表名 字段名 变量名 统一小写, 部署过web服务的童鞋应该颇有感悟, 的Mysql默认不区分大小写但Linux的Mysql是区分大小写的所以为了避免节外生枝, 请尽量使用小写
简明易懂, 虽然我们提倡字段的命名尽量简洁, 但是不能过于间接导致阅读障碍, 良好的习惯是 不要使用单词的简化形式 除非大家都懂 比如 -> info ,-> stu因为我们开发的数据库 毕竟要给各方面人员查看和使用 应该避免这种沟通成本
表达是否的含义尽量不要使用is做前缀 而采用后缀标识, 这个其实我阅读阿里巴巴开发者规范 和阿里巴巴数据库设计规范 得出的结论
不过细心的同学就会发现一个有意思地方, 在开发者规范中提到 由于RPC在逆向解析的时候 对is开头的会无法识别, 所以阿里不建议我们使用is开头, 但是在数据库规范的中 阿里强制我们使用is做字段的前缀 这就很有意思了 口说无凭