有张表有 120 多个字段，我该怎么处理呢？

[t298]

业务现在要保存一些信息，字段加起来有 120 多个字段在一张表里。我按照类型区分了一个，可以分成 8 张表，但是我总不能分到 8 张表里来处理吧，那就是 8 表联查了。然后我又想到可以存成 json 格式，把以前一个表存成一个 json 字段，这样这个表就只有十来个字段了，可能又发现会有一对多的关系，比如表里有个字段是水库，一行数据里会有多个水库，那这样就又没办法存了，有老哥教我一手怎么处理嘛？数据库是 mysql8.0

[Kontinue]

查表，有多表联查的可以考虑建一个视图？

[Maboroshii]

套一下数据库设计范式吧

[Cloud9527]

听你描述感觉 MongoDB 更合适啊

[corcre]

一对多存多个表好像没什么问题, 我司 8 表联查好像也是家常便饭...
(其实主要还是看你的数据量

[Twnysta]

主表尽量多的搜索字段，只展示字段挂到别的表，搜索出第一张表的结果后，用 id 去 whereIn 取展示内容

[awanganddong]

刚开始想那么多干嘛，能跑就可以了，关系型数据库本来就是这么用的，以后同步数据到 es 也可以。

[quicksand]

@Twnysta 但是关联太多表这种 where in 写起来也挺烦人的，不知道有没有更好的选择

[lyz1990]

嫌麻烦就不改吧，能跑就行，哈哈

[wangritian]

访问量不高的话，先别动了

[aw2350]

postgres ,json 类型字段存储非重要数据

[DinnyXu]

相同的数据存字典，建立枚举关系。比如 1-10 个字段，是一个组合，可以把这些组合合并为一个字段，然后映射对应的枚举

[totoro52]

120 个字段，拆成 8 个表，做查询的时候关联 8 个表？ 那是个什么样的画面 太美了不敢相信
看业务需求来
如果你的前台涉及到一个复杂查询，多种条件合并查询，这种我就建议上 ES 或者一些轻量的搜索引擎，你如果真把他拆成 8 个表做关联那效率你在怎么优化都不行的
如果你的前台不涉及复杂查询，那我建议拆表，拆完后采用代码连表，效率也会提升很多
总的来说，我的建议是不要动最好

[totoro52]

如果的数据量不多的话完全不需要考虑 ES 之类的，做好数据库优化，然后大胆去拆就好，一些非必须 SQL 连表的采用代码方式填充效率会来的更好一些。

[N9f8Pmek6m8iRWYe]

又不是不能用

[ShuWei]

抛开业务场景和需求谈设计，是耍流氓

[cheng6563]

要 WHERE 的列放主表，其他的丢附表用多字段或者 JSON 随意放就行了。

[rapperx2]

能用就行

[xshell]

设计问题，挖坑

[Felldeadbird]

能跑就好了。我公司的产品表已经 127 个字段，明天又加一个字段咯。 这么多字段全部都是伪需求，A 提一个需求，结果 A 不用。

[seakingii]

最好的办法是：

不要改动