相同属性的多种可能的数据类型: null条目，EAV，还是存储为varchar？

Question

我正在为燃烧实验建立一个数据库。每个实验都有一些我称之为“细节”的科学元数据。例如(“燃料”、“C2H6”)或(“压力”，120)。因为相同的细节名称(比如“燃料”)会显示很多，所以我创建了一个表来存储名称和单元。以下是一个简化的版本：

CREATE TABLE properties (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    units NVARCHAR(15) NOT NULL DEFAULT 'dimensionless',
);

我还创建了一个名为“details”的表，该表将“属性”映射到值。

CREATE TABLE details (
    id INT AUTO_INCREMENT PRIMARY KEY,
    property_id INT NOT NULL,
    value VARCHAR(30),
    FOREIGN KEY(property_id) REFERENCES properties(id)
);

这并不理想，因为value属性有时是化学名称，有时是浮子。将来，甚至可能会有具有整数值的新条目。将所有内容存储在VARCHAR中似乎是浪费的。既然以后很难改变，我现在就想做出正确的决定。

我已经研究了几个小时，并考虑了四种选择：

1. 在value (最简单的开发)下将所有内容存储为varchar
2. 使用EAV模型(最复杂的开发)。
3. 为每种类型创建一个列，并有大量的空条目。value_float, value_int, value_char
4. 使用JSON数据类型。

从每一个角度来看，他们似乎都在不同的方面都很糟糕。(1)是不好的，因为它占用了额外的空间，我必须执行额外的操作来将字符串解析为数字值。(2)由于复杂性的大幅增加(增加了四个表和更多的连接操作)，而且我听说要避免EAV，这是不好的。(3)在复杂性方面是一个中间点，但每个表项都有两个空值。(4)似乎类似于(1)，我不知道它可能会更好或更糟。

--我不希望这个数据库或数百万条目有巨大的增长。它只是需要快速和可供研究人员搜索。为了获得更好/更快的用户体验，我愿意拥有更多的后端复杂性。

到目前为止，我意识到在数据库设计中没有那么多明确的答案。我只是想了解一下我的三个选择，或者另一个我还没有想到的选择。

编辑：添加JSON作为选项。

Answer 1

好吧，你得神圣化一些东西。HD空间，或性能，或特定/一般维度或容易/复杂的发展维度。选择一个适合你的需要和情况的混合物。-2000年，我用一种通用的EAV解决方案解决了这个问题:基本记录具有大多数事件共享的公共属性，然后连接到没有值的属性(关联表)，以及那些我在XML标记中存储在BLOB中的非常具体的属性/值。通过这种方式，我将频繁的属性与那些非常具体的属性结合起来。因为这是一个非常普遍的解决方案，你可能不需要，我会牺牲空间，它今天很便宜。如果你占用的空间比“根据数据建模理论是正确的”更多，谁在乎呢？好的数据模型将是丑陋的，那又如何呢？-您仍然需要决定特定的/一般的维度--如何解决特定的属性--或者作为特定的列(如果经常重复的话)或者在属性中-TypeOfProperty-值类型的表。