我正在构建一个包含数百种不同产品类型的产品目录。这些产品类型具有许多不同的属性。有些是共享的，但大多数是特定于产品类型的。
我最初的想法是采用 EAV 类型的结构，但我明白为什么这可能是一个糟糕的选择。特别是因为我希望我的数据库强制执行正确性和一致性，这将对 EAV 造成困惑。
在我的例子中，替代方案是类表继承。不过我有点担心可维护性......我将如何维护数百个迁移和模型？这真的是一个理想的情况吗？我了解这些好处，但可维护性不是一个巨大的缺点吗？
最佳答案
这里有一个替代方案，类似于 EAV，但特别考虑了相同类型产品之间的“一致性”。
表格列表: 产品 产品类型 属性 ProductTypes-属性-允许 产品属性
Product-Attributes-Allowed 对产品类型有外键，对属性有外键。如果表中存在产品类型和属性的特定组合的条目，则该产品类型可以具有该属性。
Product-Attributes 使用 FK 直接引用 Product 和 ProductTypes-Attributes-Allowed 表。 Product-Attributes 表将包含特定于该产品的信息，而 Attributes 表包含有关一般属性的信息(显示名称、单位等)。您将不得不跳转一个额外的表以将属性值与属性“元数据”链接起来，但您至少可以强制执行产品类型相似性。
编辑，不适合作为下面的评论:
@Willem-Aart 这些都可以是存储在“属性”表中的属性的属性。例如，您可以有一个字符串“DataType”，它包含有关要存储在“Product-Attributes”表中的值的数据类型的信息。这将需要将数据存储为 Product-Attributes 表中的 blob(或其他一些通用可转换数据类型，如 char[])。或者，您可以为每个预见的数据类型设置单独的列，并将属性的“错误”数据类型留空。您可以有一个强制至少一列为非空的约束。
要强制执行一系列值，至少对于数字属性，您也可以将它们设置为属性表中的列。例如，“Max_Allowable_Value”。
向数据库添加功能/灵 active 通常会增加复杂性。
关于mysql - EAV是 'bad'，但是类表继承的可维护性如何呢？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39195762/