如何重新设计EAV表

Question

我们的MySql数据库中的大多数表都不是EAV tables。我一直在阅读 SQL Antipatterns ，我正在尝试确定重新设计此表的最佳方法。我知道我们会喜欢弹簧形式中更容易引用的好处和更好的数据完整性。

EAV table具有可能带有费用的可选属性。在代码中，现在有55个选项，而且这个数字还在不断增长。每笔费用的平均属性数为2.719，使用的单个费用最多为39个属性。

在这种情况下，创建一个包含55个以上选项的表格是理想的，还是下一个必须保持表格大小的人？

Answer 1

这听起来是调查document-oriented storage作为替代（非SQL）设计的好时机，其中EAV三元组可以存储为例如： MongoDB中的JSON数据。您没有为此定义架构，因此查询语法与SQL不同，但在某些情况下它可能更强大。例如，我最近看到一个关于使用这种设置的演示文稿，使用RDF创建linked-data商店，然后RDF形成一个支持其他服务的公共层，例如： REST，webservices，XMLRPC等。使用所有标准化的数据显然更容易做到这一点。

有关这是否是一个好主意的更多想法，请参阅this question。