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

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

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

以前经常能够看到,数据库范式,现在说数据库三大范式的少了。

三大范式我以前也很严格的弄过,但是后来发现,还是灵活好啊,为什么,业务变动太快了啊,按照范式来,结构变更顶不住。

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

 

外键、触发器

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

 

自增id

数据库表,一定要有id,而且要用自增id! 有些人喜欢用自定义的,用UUID或者其他七七八八的id,如果在架构设计,代码比较好的情况下,不会出啥大问题,但是一旦代码写的不行,极有可能就造成id重复之类的问题。 自增id另外还有一个好处,就是在数据迁移的时候,分页查询通过id来进行分页,速度会比传统分页快很多。

 

创建时间&修改时间

创建时间和修改时间这两个字段,每个表都要有! 注意,一定要用数据的时间戳,自动生成。不要通过代码去操作这两个字段。

有了这两个字段。你可以追溯到数据的时间点,创建和修改的时间点。极大方便你在某些情况下的排查数据问题。

 

创建人&修改人

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

还是和前面一个原因,出问题的时候可以追溯起因,否则遇上日志过久无法查看或者其他原因出现未知数据,都不知道数据怎么来的,需要花非常大的代价查看日志、代码等。

 

大文本字段

一列需要占很大空间的字段,一定要单独拎出来,不要和常用信息放一张表。

举个例子: 文章的信息和文章的内容,这一定要分成两个表。否则会给你的文章性能带来极大的挑战。因为很多情况下,查看文章列表,根本不需要查看到文章的内容。

 

表与表的关联

表与表之间的信息,用id进行关联,尽量不要有冗余的信息数据,否则你需要更新同一份信息的时候,需要更新多个地方。

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

 

单库单表单系统写原则

这个原则我自己想出来的,也就是说,数据库中的一张表,只能有一个系统对其进行写操作。 其他的系统如果想写这张表,那么经过调用这个系统的接口进行操作。

如果有多个系统写同一张表,可能带来的问题会很多。首先就是数据并发问题,其次就是事务问题,还有就是表结构变更问题,数据来源追溯问题等等。

如果谁有一张表数据想用多个系统来进行写,那肯定是想把团队拖垮。时间越久,债务越多!

 

总结

数据库设计,标准其实是在变的,不变的只是思想。

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

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

上云就看云栖号:更多云资讯,上云案例,最佳实践,产品入门,访问:https://yqh.aliyun.com/

本文为阿里云原创内容,未经允许不得转载。

你可能感兴趣的:(作为后端开发如何设计数据库系列文章(一)设计传统系统表结构)