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

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

首次尝试是在EAV和Table Per Class db继承建模之间进行选择.我之所以选择后者是因为它的性能,但它的意思是为每个特定的(类别树中的叶子)产品类别创建专用表,其中特定的类别属性(如电视的分辨率)被建模为单独的列.

如果您需要在现有类别中添加属性或添加新类别,则此设置不具备灵活性.对于每个此类更改,需要以下内容:

更改/创建表

通过特定属性过滤此类别的新表单

用于生成用于搜索和过滤的数据库查询的新代码

一些新的视图模型/ DTO和用于展示新类别产品的视图

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

那时我已经了解到ebay并没有真正使用关系数据库进行搜索,并且他们的分类法非常灵活,他们可以很快地添加新的叶子类别.此外,它们的类别可能不是来自关系数据库中建模的分层树的类别,而只是搜索属性(构面).

在快速浏览了最有前途的专用分面搜索设置(单独的Solr实例)之后,我不确定它是否可以帮助我灵活地进行分类更改,因为通常Solr只是以某种方式镜像关系数据库,所以特定的类别属性仍然需要在DB中建模为DBMS元数据,例如.动态生成用于过滤属性的UI表单很难,除非:

1)我会使用EAV fasion将数据保存在RDBMS中并使用SOLR搜索克服其性能问题(但是仍然存在EAV混乱问题,没有数据完整性强制执行等)

2)我只保留RDBMS中的属性字典(即它们的名称和类型),并将特定属性值存储在SOLR中,使用它作为除搜索工具之外的非关系数据存储.我也不相信这个解决方案(即使它是可能的),因为应用程序将与solr紧密耦合(即产品版本管理CRUD将直接与SOLR交互).

你的想法是什么？您是否认为对于任何此类(高性能)分类法灵活性代码生成是不可避免的？你会怎么处理？也许在数据库中EAV时代的一些单独的数据字典仅用于代码生成目的？我想我也可以使用像MongoDB这样的东西,但是UI代码生成(运行与否)仍然需要某种元数据.

这里有很多问题,但我不想把它分解成更小的问题,因为我在处理更大类的这类问题时对一般的设计方法感兴趣.