表单生成器，如金数据，是如何对字段数据进行存储的? 想知道如何用 MySQL 设计结构

[TOTOP]

想在后台做个表单生成器，但存储感觉有点难，请大神讲解一二

[murmur]

有什么难的呢，你可以说一下，除了搜索部分比较纠结，存储很简单的，直接用代码动态建表，不要管性能，也别管浪费，直接 select * 全弄出来，然后跟着前端 json 一套，就出来了，只要不是涉及计算的字段全给他 varchar 拉爆

子表也类似处理，这样就是子表不支持搜索，能搜性能也太差了

[murmur]

字段的 id 可以自动生成，直接 field1 ，input2 ，text3 ，datetime4 这样，或者随机，拼音自动转都行

[TOTOP]

@murmur 这样确实可以，存储是没多大问题，最主要的多建表 一个表单一个表太浪费了，最好可以设计三表关联起来就能存储，搜索起来也非常方便，我想到的是只能横向 kv 存储数据，但这样表单改动及搜索很不方便

[murmur]

@DreamCMS 一个表单就是一个业务，怎么浪费了，是按业务计算表的个数，传统 sql 设计 1 对多不就是开子表么

这样设计做报表是爽的，他除了字段难看点跟传统表设计没太大区别

[TOTOP]

@murmur 业务量不大这样设计确认也没问题，确认用起来也挺爽，但生成表越来越多的时候，类似金数据，我觉得应该不会这样设计吧

[murmur]

@DreamCMS 低代码、拖拽开发太多了，人家本身就是面向中小企业的，表多不是问题，你用列数据库行增长不也得考虑，企业审批就是业务固定字段巨多，别人一行存 30 个字段，你就得拆出 30 行了，用 kv 的话，行数据库还能保留个 date 类型，你用 kv ，真的全 string 啊

[TOTOP]

@murmur 确实理是这个理，还是没发现到最优的解。

[devswork]

建议你看下 form-create 。存储字段的话，就是有组件表（ id,component_type,label,options ），表单表（ id,title ）,表单结构表(id,form_id,component_id)，业务数据表(id,form_id,component_data_json)

[TOTOP]

@devswork json 存储搜索不方便