产品目录架构设计

Question

我正在为产品目录构建一个概念验证模式，以取代我们使用的非常老化和苛刻的产品。

在我们的业务中，我们销售物理材料和服务（一次性和重复出现的费用）。

当前目录模式将每个不同的类别分解为单独的表，虽然这很好地规范化并且运行良好，但是很难扩展。向特定产品添加新属性涉及更改表模式和回溯旧数据。

我一直在想的一个想法是第3范式中基本的实体表集合，这些将包含所有产品中常见的事实。

然后，我想构建一个Entity-Attribute-Value模式，它允许使用数据而不使用模式更改以灵活的方式扩展每个实体类型。

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

我们还有许多包含业务规则和兼容性规则的表。这些将连接到基本实体表而不是视图。

我最关心的是：

• 性能 - 属性 - 实体 - 值模式是灵活的，但如果我担心，通常表现不佳？
• 更多性能 - 使用物化视图进行非规范化可能会有一些风险，我对此并不乐观。
• 复杂性 - 虽然这种模式只使用数据是灵活且可维护的，但我担心设计的复杂性可能会使未来的模式更改变得困难。

对于那些为大型企业设计产品目录的人，我是走错路吗？是否有适用于产品目录的最佳实践架构设计阅读？

Answer 1

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

我已多次说过，EAV就像毒品一样：少量使用并在适当的环境下使用，它们可以带来益处;太多会杀了你。通常，规则必须是不允许写入"Where Attribute = 'Foo'"或"Where AttributeValue = 'Bar'"行的查询。没有报告，没有显示;没有。 EAV的任何使用必须完全是动态的，并且不依赖于特定属性行值的存在。从这个角度来看，EAV就像一袋数据。它可以在报告的列表中吐出。您可以允许用户选择他们希望在报表上看到的属性。你不能做的是过滤特定的EAV值。我听说人们使用XML数据列来解决同样的问题。有人想要过滤特定属性的那一刻，就是将该属性作为第一类属性作为列的触发器。

这种折衷解决方案的难点在于执法。编写一个过滤特定属性的查询非常简单。报告设计师在受到管理层的压力后，很想做到这一点。它需要一个坚定的手在开发人员中强制执行纪律，他们从不过滤特定属性。如果无法实现这种纪律，那么我不建议将EAV结构作为一种选择。

Answer 2

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

我不认为EAV模型的性能和可扩展性问题适用于这种情况，因为应用程序将访问物化视图（上述重建除外）。类似地，非规范化的性能影响不适用于物化视图的这种用法，因为您只会从它们中进行选择。

对我来说，踢球者的复杂性是：混合EAV和正确定义的3NF表令人困惑。此外，您无法在数据库中为所有特定产品强制执行关系完整性规则和约束。

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