做为后端开发如何设计数据库系列文章(一)设计传统系统表结构

本篇为第一篇。讲解传统系统的表结构设计（Java开发）。

讲讲如何避免数据库设计的一些坑，方便后期的开发与维护。

之前常常可以看到，数据库范式，如今说数据库三大范式的少了。

三大范式我之前也很严格的弄过，可是后来发现，仍是灵活好啊，为何，业务变更太快了啊，按照范式来，结构变动顶不住。

下面我就说一说设计数据库表要注意的一些地方吧。我不是DBA，只是Java后端开发，如下是根据个人我的经验所得，至于能不能体会，看我的了。

外键、触发器

外键、触发器不要有。
有了外键、触发器，你会发现： 写代码不方便。 订正数据不方便。 迁移数据也麻烦。 总之，你要是坚持用，后续的坑等着你。

自增id

数据库表，必定要有id，并且要用自增id！
有些人喜欢用自定义的，用UUID或者其余七七八八的id，若是在架构设计，代码比较好的状况下，不会出啥大问题，可是一旦代码写的不行，极有可能就形成id重复之类的问题。
自增id另外还有一个好处，就是在数据迁移的时候，分页查询经过id来进行分页，速度会比传统分页快不少。

建立时间&修改时间

建立时间和修改时间这两个字段，每一个表都要有！ 注意，必定要用数据的时间戳，自动生成。不要经过代码去操做这两个字段。

有了这两个字段。你能够追溯到数据的时间点，建立和修改的时间点。极大方便你在某些状况下的排查数据问题。

建立人&修改人

建议每一个表也有这两个字段。

仍是和前面一个缘由，出问题的时候能够追溯原由，不然赶上日志太久没法查看或者其余缘由出现未知数据，都不知道数据怎么来的，须要花很是大的代价查看日志、代码等。

大文本字段

一列须要占很大空间的字段，必定要单独拎出来，不要和经常使用信息放一张表。

举个例子： 文章的信息和文章的内容，这必定要分红两个表。不然会给你的文章性能带来极大的挑战。由于不少状况下，查看文章列表，根本不须要查看到文章的内容。

表与表的关联

表与表之间的信息,用id进行关联，尽可能不要有冗余的信息数据，不然你须要更新同一份信息的时候，须要更新多个地方。

可是在某些状况下，你确认信息不会常常变更，且该信息确实在两个表中都有会比较好，那么，放心的去冗余吧。可是注意，数据的更新用上事务。

单库单表单系统写原则

这个原则我本身想出来的，也就是说，数据库中的一张表，只能有一个系统对其进行写操做。 其余的系统若是想写这张表，那么通过调用这个系统的接口进行操做。

若是有多个系统写同一张表，可能带来的问题会不少。首先就是数据并发问题，其次就是事务问题，还有就是表结构变动问题，数据来源追溯问题等等。

若是谁有一张表数据想用多个系统来进行写，那确定是想把团队拖垮。时间越久，债务越多！

总结

数据库设计，标准实际上是在变的，不变的只是思想。

业务场景不一样，实际需求不同，不会存在同样的设计，可是通用的思想都是同样的，为业务服务，为将来服务，方便维护，方便扩展。

这条路很长，只能慢慢在路上体会了。