[提问]用 MySQL 如何保存复杂表格的各种不同的数据。如居民健康档案表、高老糖随访表等...

[hzw94]

由于要重构系统，正在重新设计数据结构，希望找到好思路解决下面的问题

1. 表格里面值的太杂、类型太多

2. 旧表是将左列表头作为一个字段(职业、婚姻状况、疾病、手术)，将右边的值按顺序放入数组再序列化后，保存到字段中，读取显示的时候，就反序列化按顺序显示

   个人觉得比较死板，完全写死了，查询也会非常艰难。旧表是前同事设计的，我刚转正就接手了，头大中。

---

附上表格

居民健康档案

高血压随访表

[3dwelcome]

我也关注一下，目前是 axure 绘制表单，可见即可的。然后运行时，填入 json 字段，对应各种字段增减。

一直希望找一个能更好的，复杂表单布局的描述，来替换 axure 设计的表单样式。

[coyove]

postgresql json
……
……
……
不好意思走错地方了

[bk201]

mogodb，不用动脑子

[changwei]

mysql 的 json 不错，但是听说查询起来性能比较低？试试看 mongodb，他专门就是为楼主这种场景需求设计的。

[yumemor]

之前有做过类似的项目，不过是管理简历，每个人的职位信息技能专长 ／个人信息／ 教育信息 字段很多，当时放弃了用数据库持久化 我是用了 xml 文件进行持久化的，而数据库只关联一些用户和简历的相对路径，主要很方便的是 xml 节点命名稍微注意点 很容易就能生成一个 html 然后导入一个 css 进去，样式也有了，对维护来说 xml 可读性也比 json
强。

[sorra]

@yumemor 这样保存就不能查询内容了。如果不需要查询内容，用数据库的 BLOB 保存更简单。
@hzw94 查询速度主要靠事先建索引，如果你先想好哪几个字段经常查询，可以把这几个字段重复保存到几个专门的 column，用来建索引。即使是 NoSQL 也要建索引才查得快，NoSQL 的索引相对灵活一些。

[yumemor]

@sorra 全文检索 ，可能效率低 存二进制场景可能更适合来备份

[YangXiaoming]

该用 PostgreSQL9.6，用 jsonb 字段存一些比较灵活的信息，查询检索都方便。。。

[buliugu]

持久化存 mysql json，有事务安全，要查询直接上 es 好了

[reus]

肯定用 postgresql 的 jsonb 来存啊，然后做一些索引，或者直接顺序处理
postgresql 支持表达式索引，也就是 jsonb 里存的值，用一个表达式计算出来，然后做索引
十分灵活，比 mysql 好五倍

[cxbig]

一般 MySQL 就就是 JOIN，1 对 1 的信息放主表（ Person:id ），其他可能有多次记录的按功能单独出一个表，如（高血压 Hypertension:id,person_id ），Person has many Hypertension 这样。分表有字段增减用 ALTER TABLE 即可

至于 MongoDB 这种就更简单，可以任意增减 Field，在程序层面包装好 json 即可。

[leeg810312]

Postgresql jsonb+1，jsonb 存取方便，查询性能一点也不差

[Sunyanzi]

看起来并不是很复杂啊 ... 用 JSON 确实是个方法 ... 但对于这种字段基本定死的表格也可以不用 ...

不太明白表一里面除了生日之外的小方框是做什么用的 ... 如果是分类勾选一个二进制就搞定了 ...

所有涉及自定义填写的无非就是一个个的 nullable 的字段 ...

手术外伤这种如果确定只能写俩就是单表两组字段 ... 允许无限量填写的话开子表也没什么问题 ...

从示例的这两张表来看就是两张有四五十个字段的大表 ... 还挺基础的其实 ...

顺便说句题外话 ... 改动表体系等于改动所有业务逻辑 ... 如果接手的时候原来的数据很多还是慎行 ...

毕竟老系统很多都没有 API 类的东西 ... 所有子系统都是直读表 ... 如果要重构建议妥善评估后果 ...

[gouchaoer]

存成 json 没问题。。。。别用 mongo 别用 postgres，就用 mysql 就 ok 了，如果没有检索统计需求你上一位的方法没问题，有就使用 json 类型

[dylanninin]

up

[dylanninin]

看楼上很多在 mysql/postgresql/mongodb 之间徘徊，感觉没有真正理解问题本身，而是手中各自拿了一把🔨

根据接触过的项目，就楼主的问题回答一个很普通、也很朴实的做法，希望能够开阔思路。

按照字段名、取值范围等逐一列举，没有 json、没有 schemaless，一样可以非常好的工作。
- 1. 字段类型多、取值多，都不是问题，先下一个基本功『列举 /枚举』，在此基础之上再进行分类、归纳、抽象，这对后续的设计调整、代码实现都有帮助。当然，很多人一眼就可以看出这很死板、繁琐，就不愿意去做了:-D
- 2. 按照关系数据库来设计，最基本的一张表，记录各种表格的所有字段的元信息，比如 fields(id, target, name, type, label, description, default, nullable, options)，包括业务表类型，字段名、字段类型、字段标签、字段描述、字段默认取值、字段是否为空，字段取值的可选项等，甚至也可以增加 validator 等等
- 3. 动态创建表，根据以上 fields(target) 就可以知道一个 target 的所有 field，动态建表很容易
- 4. 至于查询，跟 json/schemaless 无关，照例可以根据 fields 来生成查询的模板

以上设计很普通，相信大家都能够想到 ~

[dylanninin]

忘记补充，代码实现方面，如果对元编程有足够了解，实现起来也会很简单

[dangyuluo]

@buliugu 所见略同

[jucelin]

和问卷系统类似： https://wj.qq.com/s/1421356/252b
可以简单除暴的视为： 问题 /答案，然后再拓展相关的字段。这样你就不会认为你的选项没有规律了。

高血压随访表 可以拆开理解为每次都填一次问卷。

之前做问卷系统的时候，拿到的需求和你这个一样，密密麻麻的框。

[m939594960]

在我们公司做个好几个类似的程序，都是 mysql 疯狂建表，然后存起来，然后这页面一查表能查 20~50 个连表（我是真的服了，但是数据库我又控制不了）我就建了一个新字段，第一次查询的时候吧这些数据链表放到模板里生成 html 下次到这页就不连表了，查询功能也可以做的 OK