我在一家工业机械制造公司工作，这是我们使用 SQL 的第一种方法。我们的客户要求采用全新的机器设计，以在 MySQL 数据库中保存所有相关的生产数据（即产品序列号、生产日期、质量检查...）和一些传感器读数，以供将来分析和质量控制。
这不是什么大问题，因为我们可以轻松地将 PLC 连接到 SQl 数据库，并且生产历史记录表不会很复杂。
我们唯一的疑问是实现“食谱”表的最佳方法，该表可能会达到过多的列数（超过 100）。
对于机器能够生产的每个产品代码，我们都会创建一个配方，其中包含其特定生产所需的所有数据（即温度、尺寸、时间等），并且通常所有这些数据都存储在 HMI 屏幕中机器的。大多数工业 HMI 都有用于配方管理的特定工具。
通常一个标准菜谱由一个id号（整数）、一个名称（字符串）以及一定数量的整数和实际数据组成。作为我们机器上的标准，我们为此任务预先分配 50 个整数和 50 个实数，但如果机器很复杂，我们会将配方大小扩展到 100 个整数和 100 个实数。
我们始终为未来的修改保留安全余量。
问题是，如果我在如下所示的 SQL 结构上声明一个“配方”表，其中每个数据都有一列，那么它将很容易超过 100 列，这似乎不是最佳方法。
|编号 |名称 | int_1 | int_2 | ... |整数_100 |真实_1 |真实_2 | ... | Real_100 |
有没有办法重构“食谱”表，或者在这种情况下我可以拥有如此多的列？
感谢您对我原来的问题的评论。根据建议，我们将继续采用 EAV 方法。
“菜谱”表将分为 3 个表：
表 1（实体）-“配方”
| recipe number (PK) | name |
表 2（属性）-“配方属性”
| attribute name (PK) | type | description |
表 3（值）-“配方值”
| recipe number (FK) | attribute name (FK) | value |
这个方法对我们来说绝对有好处。
非常感谢您的支持。