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

时间:2020-04-22 作者:管理员 点击:1034

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

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

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

外键、触发器

外键、触发器不要有。

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

自增id

数据库表,一定要有id,而且要用自增id!

有些人喜欢用自定义的,用UUID或者其他七七八八的id,如果在架构设计,代码比较好的情况下,不会出啥大问题,但是一旦代码写的不行,极有可能就造成id重复之类的问题。

自增id另外还有一个好处,就是在数据迁移的时候,分页查询通过id来进行分页,速度会比传统分页快很多。

创建时间&修改时间

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

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

创建人&修改人

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

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

大文本字段

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

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

表与表的关联

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

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

单库单表单系统写原则

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

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

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

总结

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

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

这条路很长,只能慢慢在路上体会了。
返回列表
在线沟通

Are you interested in ?

感兴趣吗?

有关我们服务的更多信息,请联系

136 7365 2363(同微信) 13140187702

郑州网站建设郑州网站设计郑州网站制作郑州建站公司郑州网站优化--联系索腾

与我们合作

郑州网站建设郑州网站设计郑州网站制作郑州建站公司郑州网站优化--与索腾合作,您将会得到更成熟、专业的网络建设服务。我们以客户至上,同时也相互挑战,力求呈现最好的品牌建设成果。

业务咨询热线:

136 7365 2363

TOP

QQ客服

在线留言