瞎扯淡 这样设计合理吗

noob · 2018年09月04日 · 最后由 hooopo 回复于 2018年09月06日 · 1568 次阅读
  1. 一个数据表中 50 多个字段,合理吗?

  2. 表中明明有关联字段,还要存很多关联表中的其他字段,说是为了查询方便,合理吗?

合不合理,取决于你说了算不算。

项目中经常增加一些冗余字段来方便查询,主要看业务场景。不过这个 50 多个字段维护起来确实有点头疼,可以适当拆分成两到按个 tb 去处理

可以有适当的冗余,但核心点还是要根据实际的业务需求来。。 问题没想清楚,就先不要去想问题的解决方案。

遇到过一个情况, 比如说一个订单, 有很多货品, 然后通过中间表建立关联, 中间表就存了两个 id, 后面当删除了货品, 查看订单,就没数据了, 所以要么就需要在中间表中存上货品相关的信息,要么就做一个软删除才行

数据量很大的时候,需要这样的星型表,关联查询很可能搞不动的

这要看业务了,如果不长更改的字段,为了查询,有少量冗余字段也没所谓,而且查询确实方便,但如果比较容易更改的字段就建议不要这么做,同步数据很麻烦,得不偿失

每个数据库不同,比如 mysql 限制了一个表的最大字段数为 4096
当然由于有 row limit,可能达不到这个数
具体可以参考这里

上百个字段的表目前还没没遇到过,即使是上百个字段也不能说一定不合理,
合理不合理跟你保存什么内容、如何使用等等有关

我觉的应该首先分析这个表 50 个字段导致了哪些问题让你感觉不合理
分析完以后才能判断是不是真的不合理
如果知道是如何变成这样的那就更好,有时候知道原因以后或许有种原来如此的感觉

解决掉不合理的问题,应该就变成了合理了 (暂时)

从实际业务来看,是不是要加冗余字段是根据你的业务逐步发展来看的。 项目刚开始的时候,各个表都严格遵守第三范式,哪怕是好几个表的 join 也没啥问题。 后来数据多了,你发现 join 完了数据量极大,一个 ransack 的查询就要 1 秒多,那必然要看怎么才能快一点。 快一点的话,无非是冗余或者 cache 或者直接搜索切换 es。 所以你的问题如果不带着场景,谁也没法判断合理还是不合理。

有些数据需要做快照。。。。。所以会存多余的关联关系。。。

50 个字段,如果都是类似 profile 之类的属性应该没啥问题。。。要是有 50 多种关联关系,那就坑了。。

liuminhan 回复

订单的必须需要存下单时的商品信息吧,关联的话,如果商品修改了,查订单详情的话就是修改后的商品信息了

lehf 回复

是的,才发觉这个问题,要重新设计下表了

没有具体业务场景,谈什么合理不合理

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册