产品属性的数据库架构

Question

和很多人一样，我正在寻找Products /Product Properties 数据库架构。我正在使用 Ruby on Rails 和 (Thinking) Sphinx 进行多面搜索。

要求：

• 添加新产品类型及其选项不需要更改数据库架构
• 支持使用 Sphinx 进行分面搜索。

我遇到的解决方案：
(See Bill Karwin's answer)

选项 1：单表继承

真的不是一个选择。该表将包含许多列。

选项 2：类表继承

Ruby on Rails 会在启动时缓存数据库模式，这意味着每当引入新类型的产品时都会重新启动。如果您有一个大小合适的产品目录，这可能意味着数百个表格。

选项 3：序列化 LOB

无需繁重的应用程序逻辑即可进行分面搜索。

选项 4：实体-属性-值

出于测试目的，EAV 运行良好。 However it could quickly become a mess and a maintenance hell as you add more and more options (e.g. when an option increase the prices or delivery time).

---

我应该选择哪个选项？还有哪些其他解决方案？有没有我忽略的灵丹妙药（哈）？

Answer 1

IMO，类表继承和 EAV 的组合以及一些严格的限制将是最好的方法。

EAV 就像药物：少量和少数情况下，它们可能是有益的；太多会杀了你。 EAV 作为架构的主要部分将失败。没有问题。但是，作为对良好数据库模式的补充，如果您实施适当的限制，它们会很有用。

EAV 的主要规则是您永远不能编写包含'[AttributeCol] = 'Attribute' 的查询。换句话说，您永远不能过滤、排序、限制范围，也不能将特定属性放置在报表或表单的任何位置。它只是一袋数据，可以完全吐出在报告或屏幕上的列表中。事实上，我已经看到人们将此功能实现为 Xml 列。

如果您能够保持此限制，那么您可以将 EAV 结构添加到类表继承设计中，作为允许用户将一组属性添加到产品中的一种方式，仅用于存储目的。当他们想要使用属性执行任何禁止任务时，它必须成为一流的列以及所有相关内容。

关键在于执行。如果您认为您不能合理地强制执行或让其他开发人员强制执行对 EAV 结构使用的限制，那么跳过它可能是有意义的。但是，如果您可以强制执行此限制，则可以解决人们希望添加大量属性仅用于存储和跟踪目的的问题。