1

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

要求：

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

我遇到的解决方案：（
见比尔卡尔文的回答）

选项 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 (eg when an option increase the prices or delivery time).

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

4

1 回答 1

2

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

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

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

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

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

于 2010-05-04T14:25:55.447 回答