大佬们，请教一个数据库设计的问题

有没有这种查询需求，查询指定长度范围的列？如果没有，直接丢一个字符串，字符串是个 json 。如果有，看看你的数据库对 json 的支持怎样

直接存 json

如果用不到复杂聚合查询，json 是最好方案。

@Ketteiron #3
@Gilfoyle26 #2
@NotLongNil #1 json 存是指数据库表字段为 维度、对应值 json 对象 这样的嘛，复杂查询不会有，但需要基于这些数据渲染某几个维度的复合图表

直接一个大 Json ，想怎么塞怎么塞

值这一列直接存 JSON 就行了，查询数据的话量不大也是没问题的。

如果需要根据值的内容进行查询，比如需要查询 类型=长方形 AND 长 = 123
优选 MongoDB
二嘛就是 JSON 了，支持查询的那种 {json 字段}.lOng=xxx
三就是宽表结构了

如果是不需要查询的就简单了，关系型数据库文本存进去即可
长=123,宽=234


你得先说你用的什么数据库、什么版本以及是否可以换其它数据库

JSON 正解，其他方案需要频繁动数据库结构。非常麻烦。

你要是用 pgsql ，直接存 json 。如果没有联表查或数据统计，你就存 mongodb 也可以

@xided 看你的需求呢

1. 如果你有复杂的查询统计需求，如果你有 mongodb ，存 mongodb 是最好的方案
2. 如果你们的查询不复杂，如果你的数据库支持将表字段设置为 json 类型，先确认下该数据库的 json 查询 api 是否可以满足你的查询需求
3. 如果需求只是简单的读写，你可以搞一个“字符串类型”的“数据库字段”用于存储，这个字段存储一个“json 格式”的字符串
4. 如果你有复杂的查询统计需求，又没有 mongodb ，数据库对 json 的支持也达不到你的要求，那就“宽表”

你的描述里只有数据长什么样（怎么存），如果只根据这个来设计数据结构那肯定是不靠谱的。

你至少得考虑 怎么存，怎么取，将来会怎么迭代 才能确定合理的数据结构。

如果查询时不会关心具体的属性，那肯定是所有值用一个 json 方便。
如果你的类型是有限的几个，那完全可以每个类型建一张表。
如果这些数据都是整体取出来用，那次表单存储一条数据也是可以的。

@xided #4
js
const data1 = [
{
type: '长方形',
value: { width: 100, height: 100, length: 200 },
dateTime: '2025-01-01 12:00:00',
},
{
type: '三角形',
value: { angle1: 30, angle2: 60, angle3: 90 },
dateTime: '2025-01-01 12:00:00',
},
]

const data2 = [
{
type: '长方形',
width: 100,
height: 100,
length: 200,
dateTime: '2025-01-01 12:00:00',
},
{
type: '三角形',
angle1: 30,
angle2: 60,
angle3: 90,
dateTime: '2025-01-01 12:00:00',
},
]
```
有两种方案，看你自己选择了，我喜欢第一种。

如果字段总量是确定的，那我选宽表方案，最简单好操作

哈哈，OP 遇到和我一样的需求了。

postgersql jsonb 字段存数据,关键字段做常规字段,比如 ID,创建人,创建时间,修改人,修改时间,扩展字段,编码,名称,再复杂就上 gis,求性能就上全文搜索,都是原生支持的

短期快速上线优先推荐 mongodb 或者 JSON ，但长期需灵活查询、数据规范时，建议用“主表+子表”：主表存提交时间，子表存维度、字段名、值，灵活适配多维度,更稳定。最终还是和要求的高低有关。

定义一列，为图形类型，第二列为图形参数，里面存 jaon

这个主要是看数据是不是固定的，如果是动态的，用 json 最方便，而且可以任意改动，如果是固定的，可以一张主表，然后不同图形一张表，和主表关联即可，这种就比较笨了，但是可以直接对应每个图形对象

差不多的需求，一开始用主表关联表方式开发，表建着建着就感觉太麻烦，最后还是用 json 存了一个大字段来处理了。

可以一个表，加一列表单 id ，同 id 的是同一次填写