有张表有 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 连表的采用代码方式填充效率会来的更好一些。

[stevenchengmask]

又不是不能用

[ShuWei]

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

[cheng6563]

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

[rapperx2]

能用就行

[xshell]

设计问题，挖坑

[Felldeadbird]

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

[seakingii]

最好的办法是：

不要改动

[tianmalj0613]

不影响使用就不要动，影响使用了就重新设计一个新系统吧

[keshao]

在 Mysql 8.0 版本，JSON 也支持检索。可以使用 JSON 函数对数据做一些处理的 https://dev.mysql.com/doc/refman/8.0/en/json.html

[wushigejiajia01]

除非有任务要求，不然别动了，真的
干的好，不会加钱，
干的不好，就得背锅

[Rache1]

曾经接手过一个项目，用户表有将近 300 个字段 😂

[hhjswf]

视图

[ChoateYao]

自从做了 ERP 系统之后，我觉得单表 120 个字段很正常，只需要把 1 对多的拆分出来就行了。

[hhjswf]

@cheng6563 问题在于哪天 json 里头要拿出来当条件呢，给人骂死

[stabc]

Cassandra

[PythonYXY]

现存问题是什么，业务场景是啥，建议题主给出详细说明

[qza1212]

改成单值模型

[dayeye2006199]

多表联查也没这么可怕，完全需要看索引设计和表设计是怎么样的。
一刀切觉得这个查询是世界末日的，那也别用关系型数据库了。

[cheng6563]

@hhjswf JSON 里不用索引的直接用函数筛选就是了，需要索引的挪到主表建索引就行了啊。建视图一旦涉及聚合之类的操作索引就是个玄学不更容易被骂，

[windyboy]

为什么不用 nosql

[zoharSoul]

放回一个表里