首页 > 代码库 > 关于数据库表字段冗余

关于数据库表字段冗余

今天因为数据库表设计的问题,被@红薯 说了一通。暴露了自己设计的几个问题,想通之后,发现果然自己还是图样图森破啊!这里挑一个很有想法的问题出来说。

假设有个场景。有这么几个表,我是这么设计的。

  • 用户表[user]:id,userName
  • 项目表[project]:id,projectName, user_id
  • 版本表[version]:id,versionName,project_id
  • 分类表[category]:id,categoryName,version_id
  • 内容表[content]:id,text,category_id

差不多就是这样了。看着很不错,没有字段冗余。

被@红薯 教训之后……

先提个问题,命名为问题X吧。

问题X:如果要查询某个版本下的内容列表,sql是这么写的:

select c.* from content c, category t where c.category_id=t.id and t.version_id=?

好像也没什么问题。要怎么优化这个查询呢?

这个问题我们最后再来说。讲回上面的表设计,首先,有个问题。举个例子,我要查询内容A是否属于用户U,那我应该怎么做?

  1. 查询内容A所属的分类B
  2. 查询分类B所属的版本C
  3. 查询版本C所属的项目D
  4. 查询项目D是否属于用户U,从而得出内容A是否属于用户U

这样的做法简直恶劣。此时我已深刻意识到自己弱爆之处。那怎么做呢?

冗余字段!没错,我们需要在表里添加冗余字段。如果在上述表(除了user表)都添加一个user_id字段,会怎么样呢?

首先,可以确定,每个表的user_id字段的值都不会发生改变。所以,这个字段的值从一开始设定之后,就不用再修改了。

然后,我们再回到上述的问题:查询内容A是否属于用户U。现在的做法是这样的:

  1. 查询内容A的user_id是否为用户U的id

就一步!好简单粗暴!

只需添加user_id这个冗余字段,就很大程度的方便了编码量,而且数据库的查询量也减少N倍。还有,这个字段只需要维护一次!

现在,回到问题X。怎么优化那个业务逻辑呢?

我现在的做法是:在content表中,添加多一个version_id字段,可以肯定,这个字段跟user_id字段类似,只需要维护一次。

然后问题X的sql改为:

select c.* from content c where c.version_id=?
这么简单的sql!

以上说明,实践出真知!有时候,适当的数据库冗余是个不错的选择。

关于数据库表字段冗余