Database design 用于处理动态分类法的专用分面搜索引擎-有助于提高性能还是灵活性？

我一直在考虑用类似ebay的分类法和依赖于特定产品类别的属性对典型的电子商务网站进行建模

第一次尝试是在EAV和表每类db继承建模之间进行选择。我之所以选择后者是因为性能，但这意味着为每个特定（类别树中的叶子）产品类别创建专用表，并将特定类别属性（如电视分辨率）建模为单独的列

如果需要向现有类别添加属性或添加新类别，则此设置不灵活。对于每项此类变更，需要以下内容：

• 更改/创建表
• 用于按特定属性筛选此类类别的新表单
• 用于生成用于搜索和筛选的db查询的新代码
• 一些新的viewmodels/DTO和视图，用于展示新类别的产品

为了应对这种复杂性，我认为需要在xml甚至excel文件中对这些属性进行某种元表示（即使在应用程序之外），以便在每次更改时自动生成所有提到的代码（sql/orm查询、应用程序代码、模板）。因此，它可以帮助开发，但仍然需要测试和额外的部署

在这一点上，我了解到ebay并没有真正使用关系数据库进行搜索，而且它们的分类非常灵活，可以非常快速地添加新的叶类别。此外，它们的类别可能不是关系数据库中建模的层次树中的类别，而是搜索属性（facet）

在快速查看了最有前途的专用分面搜索设置（单独的Solr实例）之后，我不确定它是否能帮助我灵活地进行分类更改，因为Solr通常只是以某种方式镜像关系数据库，所以特定的类别属性仍需在数据库中作为DBMS元数据建模，因此，动态生成过滤属性的UI表单将非常困难，除非：

1） 我将使用EAV fasion将数据保存在RDBMS中，并使用SOLR search克服其性能问题（但EAV混乱、没有数据完整性实施等仍然存在问题）

2） 我会在RDBMS中只保留属性字典（即它们的名称和类型），并将特定属性值存储在SOLR中，使用它作为一种非关系数据存储，而不使用搜索工具。我也不相信这个解决方案（即使有可能），因为应用程序将与solr紧密耦合（即ProductEdition admin CRUD将直接与solr交互）

你的想法是什么？您认为对于任何类型的（性能）分类法来说，代码生成都是不可避免的吗？你会怎么处理？也许只是为了代码生成，在DB中使用EAV方式的一些单独的数据字典？我想我也可以使用MongoDB之类的东西，但是UI代码生成（运行时与否）仍然需要某种元数据

---

这里有很多问题，但我不想把它分解成更小的问题，因为我对处理更大类别的此类问题时的通用设计方法感兴趣。

我并不声称对所有这些问题都有明确的答案（这是一个相当开放的问题，你应该试着把它分成更小的部分，这取决于你的实际需求，事实上，我很想投票来结束它）但我会评论几件事：

我会忘记在RDBMS上建模

在我看来，这不是生成代码的正确地方。您应该设计代码，使其不会随着数据的更改而更改（我不是说模式的更改）

将元数据/属性存储在Excel电子表格上似乎是一个非常糟糕的主意。我会构建一个UI来编辑它，它将存储在Solr/MongoDB/CouchDB/任何您选择管理它的地方

Solr并不“只是镜像关系数据库”。事实上，Solr完全独立于关系数据库。最常见的情况之一是将数据从RDBMS转储到Solr（过程中的数据非规范化），但Solr足够灵活，可以在没有任何关系数据源的情况下工作

在研究中仍然是一个悬而未决的问题。目前有两种不同的方法正在研究中（，）

---

如果不同类型的产品有不同类型的类别会怎样

以eBay为例，我们的产品可以是书籍或电视/显示器

书籍有书名和ISBN，可能属于科幻类、情色类、非小说类或自传体类，也可能属于非小说类、自传体性类

显示器具有屏幕分辨率和功耗（？），可以是平板显示器、CRT显示器或HD显示器

从纯关系的角度来看，您可以这样建模：

[Product]-(1)------(1)-[  Book  ]-(n)------(m)-[ book_category ]
| id    |              | title  |              |  name         |
| price |              | ISBN   |
| ...   |
| ...   |-(1)---(1)-[   display  ]-(n)------(m)-[ display_category ]
                    | resolution |              |  name            |
                    |   watts    |

您可以根据产品的类型/类别拥有不同的属性和类别，而不是根据特定产品类别对

属性进行建模

参见
Ad 1：分面搜索/导航本身不是我的优先事项，我可能会使用常规的“高级搜索”形式，并使用不同的输入数据类型（字符串、价格、范围等）Ad 2：什么是数据，什么是模式取决于一种观点。在EAV中，一切都是数据，如果我选择使用“分辨率”作为列，它将成为模式。如果我想向TVs类别添加新的属性类型（例如USB端口数）它也可以被描述为模式改变。ad 4。有趣的是，你知道这方面的例子吗？1。如果你想有层次分类，那么不，不会