聊聊数据库表结构设计心得

本文讨论是一般表的设计，有一定的普遍性和通用性，当然对于特殊性的考量则不在本文讨论之列。

自增 id

Java 层的 CRUD 都是围绕自增 id 的，以这个 id 为依据的，所以自增 id 不可或缺，每张表都应该有。当然其他类型的 id，如 uuid、雪花 id 都可以并存。

还有分页、表与表的关联都离不开这个自增 id。

createDate & updateDate

有了这两个字段，你可以追溯到数据的时间点，创建和修改的时间点，以方便查找问题。MySQL 下类型为 datetime，在 Service 层控制生成。一般精确到秒即可，如果并发量大可以考虑毫秒级别的。

creator & updater

同理，创建人& 修改人也是为了出问题的时候可以追溯起因用的，相当于日志的作用。但是这两个字段可以斟酌使用，因为涉及表关联（外连接到用户表）比较麻烦。

唯一标识

特点是全局唯一，在处理通用表的时候很好用，例如附件表，一个实体可以拥有多个附件，即一对多，那么在附件表里面有个 ownerId 对应那个实体即可，无须额外增加字段再说明哪种类型。当然于附件表本身而言，他并不知道对应的类型，要靠实体主动关联它的时候，才晓得。

唯一标识生成算法很多，我们架构采用 Twitter 的“雪花算法”。

状态 status

如果不是物理删除某行记录，那么就在数据库上面标记之。如设一 isDeleted 字段，不是不行，是每张表都要那么做。还有我们的表多数时候考虑一个“上线/下线”的状态，获取其他特定的状态。那么何不干脆将它们合并之？统一一个 status 字段好了。MySQL status 是关键字，你可改名 stat 或转义。

MySQL 下设置 TinyInt(1) 类型即可，对应 Java 设计好的常量，例如 0/null = 正常/上线状态，1=下线，2=已删除，……=不断扩充。

表关联

尽量不要有冗余的信息数据，否则你需要更新同一份信息的时候，需要更新多个地方。数据库三大范式能遵守就遵守，实在不行也不必过于拘泥，例如权衡性能的话，有时需要冗余部分数据。

外键、触发器

外键是老一代的东东，不要为自己添加枷锁。触发器看情况，虽然大部分可以用 Java 代替之，但有时妙用也可以。

存储过程、函数

老一代很喜欢用，现在通通给我用 Java 写。但有时 SQL 没法实现，就应该请益于它们了，例如 MySQL 递归查询。

分库分表

这方面本人经验不是很多，——另请看高人的——

出处 https://developer.aliyun.com/article/756689

通用结构

综上所述，给出表结构的通用字段如下。

CREATE TABLE `template` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键 id，自增',
  `name` varchar(45) DEFAULT NULL COMMENT '名称',
  `content` text COMMENT '内容',
  `uid` bigint(20) NOT NULL COMMENT '唯一 id，通过 uuid 生成不重复 id',
  `createByUser` int(11) DEFAULT NULL COMMENT '创建者 id',
  `createDate` datetime NOT NULL COMMENT '创建日期',
  `updateDate` datetime NOT NULL COMMENT '修改日期',
  `stat` tinyint(2) DEFAULT NULL COMMENT '是否已删除 1=已删除；0/null；未删除',
  `catelogId` int(11) DEFAULT NULL COMMENT '分类 id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='模版结构';