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

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

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

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

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

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

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

• Column Count Limits
• Row Size Limits

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

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

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

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

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

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

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

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

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