提问人：Alex0xff 提问时间：11/6/2023 更新时间：11/14/2023 访问量：52
实体-属性-值模式是对此数据进行建模的正确方法吗？
Is Entity-Attribute-Value pattern the right approach to model this data?
问：
为了控制实验设置，用户输入下表，该表定义了唯一的参数配置，即运行实验的参数值组合。参数的数量及其含义可以是任意的，例如，在这里，我们有 和 。ModeAmpGainInputVoltage
| 配置名称 | 模式 | 安培增益 | 输入电压 |
|---|---|---|---|
| MX1_LG_HV | MX1系列 | 1 | 3.3 |
| MX1_HG_HV | MX1系列 | 10 | 3.3 |
| MX2_LG_HV | KXt公司 | 1 | 3.3 |
| MX2_HG_HV | KXt公司 | 10 | 3.3 |
| MX2_LG_LV | KXt公司 | 1 | 1.8 |
| MX2_HG_LV | KXt公司 | 10 | 1.8 |
在我的应用程序中，这些数据需要保存在类似 SQL 的数据库（例如 SqLite）中。 从关于数据库设计模式的各种文章中，我发现实体-属性-值模式是表示此模型的一种可能方法，即：
Parameter表来描述参数
| 参数 ID （PK） | 参数名称 |
|---|---|
| 1 | 模式 |
| 2 | 安培增益 |
| 3 | 输入电压 |
Config描述配置的表
| 配置 ID （PK） | 配置名称 |
|---|---|
| 1 | MX1_LG_HV |
| 2 | MX1_HG_HV |
| 3 | MX2_LG_HV |
| 4 | MX2_HG_HV |
| 5 | MX2_LG_LV |
| 6 | MX2_HG_LV |
最后，将表组合在一起，其中 和 形成一个主键：ConfigIDParamID
| 配置标识 | 参数 ID | 值Int | 值浮动 | 值斯特 |
|---|---|---|---|---|
| 1 | 1 | 零 | 零 | MX1系列 |
| 1 | 2 | 1 | 零 | 零 |
| 1 | 3 | 零 | 3.3 | 零 |
| 2 | 1 | 零 | 零 | MX1系列 |
| 2 | 2 | 10 | 零 | 零 |
| 2 | 3 | 零 | 3.3 | 零 |
| 3 | 1 | 零 | 零 | KXt公司 |
| 3 | 2 | 1 | 零 | 零 |
| 3 | 3 | 零 | 3.3 | 零 |
| 4 | 1 | 零 | 零 | KXt公司 |
| 4 | 2 | 10 | 零 | 零 |
| 4 | 3 | 零 | 3.3 | 零 |
| 5 | 1 | 零 | 零 | KXt公司 |
| 5 | 2 | 1 | 零 | 零 |
| 5 | 3 | 零 | 1.8 | 零 |
| 6 | 1 | 零 | 零 | KXt公司 |
| 6 | 2 | 10 | 零 | 零 |
| 6 | 3 | 零 | 1.8 | 零 |
这是实现 EAV 模式的正确方法吗？ 考虑到参数不会超过 25-30 个，并且这些数据每分钟只需要访问/保存一次，有没有更好的方法来对数据进行建模？
答：
0赞
Alex0xff
11/14/2023
#1
我最终决定将这些参数序列化到 JSON 字段中，正如 @Panagiotis Kanavos 所建议的那样。这比实现EAV模式要麻烦得多，而且，许多ORM框架都支持访问JSON字段。
评论