Sql 产品目录模式设计

我正在为一个产品目录建立一个概念验证模式，以可能取代我们使用的一个非常陈旧和粗糙的目录

在我们的业务中，我们销售实物材料和服务（一次性和重复收费）

当前的目录模式将每个不同的类别分解为单独的表，虽然这很好地规范化了，并且执行得很好，但是扩展起来相当困难。向特定产品添加新属性涉及更改表架构和反填充旧数据

我一直在玩弄的一个想法是，在第三范式中的一组基本实体表，这些表将包含所有产品中常见的事实

然后，我想构建一个实体属性值模式，该模式允许以灵活的方式扩展每个实体类型，只使用数据而不使用模式更改

最后，我想将此数据模型反规范化为每个实体类型的物化视图。应用程序将访问这些视图

我们还有许多包含业务规则和兼容性规则的表。它们将根据基本实体表而不是视图进行连接

我最关心的是：

• 性能-属性实体值模式是灵活的，但通常性能很差，我应该担心吗
• 更多的性能-使用物化视图进行非规范化可能会有一些风险，我还不确定这一点
• 复杂性——虽然这个模式是灵活的，并且只使用数据就可以维护，但我担心设计的复杂性可能会使未来的模式更改变得困难

---

对于那些为大型企业设计产品目录的人来说，我是不是走错了路？产品目录中是否有任何良好的最佳实践模式设计阅读资料？

有一个单一的通用产品表是一个好主意，但我不确定在特定行中使用EAV会获得什么好处。在您的解决方案中没有额外的灵活性：如果您添加一个新产品，您需要一个新的物化视图；如果将新属性添加到现有产品中，则需要重新定义和重建物化视图，这与反向填充数据没有什么区别（除非可能需要更长的时间）

我不认为EAV模型的性能和可伸缩性问题适用于此场景，因为应用程序将触及物化视图（除了前面提到的重建）。类似地，非规范化的性能影响不适用于这种物化视图的使用，因为您将只从中进行选择

对我来说，关键在于复杂性：混合EAV和正确定义的3NF表令人困惑。此外，您还失去了为所有特定产品在数据库中强制实施关系完整性规则和约束的能力

---

我认为一个更好的解决方案是保留建议的PRODUCTS表，并为各个行使用子类型表。一旦你开始建模，你可能会发现你需要为不同类型的产品（服务产品和东西产品）建立一个表格层，而相对较少的特定产品需要自己的表格。您可以使用常规视图显示每个产品的“非规范化”投影。

我只处理过多租户应用程序中的法律合同而不是产品中的类似问题。有些属性是所有人的共同属性，有些是用于跟踪的任意属性

我已经说过很多次了，EAV就像药物一样：在适当的情况下少量使用，它们可能是有益的；太多会害死你。通常，规则必须是，不允许写入沿

“Where Attribute='Foo'”

或

“Where AttributeValue='Bar'”

行的查询。没有报告，没有显示；没有什么。EAV的任何使用都必须是完全动态的，不依赖于特定属性行值的存在。在这种情况下，EAV就像一包数据。它可以在报告的列表中显示出来。您可以允许用户选择他们希望在报告中看到的属性。您不能做的是筛选特定的EAV值。我听说人们使用包含XML数据的列来解决同样的问题。当某人确实想要筛选某个特定属性时，即触发将该属性作为列作为第一类属性

---

使这一折衷方案难以实施的是强制执行。编写一个查询来过滤特定属性非常简单。报表设计人员在受到管理层的压力后，很可能会这么做。它要求开发人员严格遵守纪律，他们从不过滤特定属性。如果这种规则无法实现，那么我不建议将EAV结构作为一种选择

您计划使用什么数据库？MySQL没有物化视图，不过你可以一起破解类似的东西。我们将使用一个真实的数据库。我应该澄清一下。非规范化视图不会将EAV翻转为列而是行，因此它们会随着数据的增长而增长。EAV模式不会用于每个产品，而是用于定义产品属性，例如，“重量”将是一个应用于实物的属性，而不是服务，因此它将是一个属性。