首次尝试是在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代码生成(运行与否)仍然需要某种元数据.
这里有很多问题,但我不想把它分解成更小的问题,因为我在处理更大类的这类问题时对一般的设计方法感兴趣.
解决方法
>我会忘记在RDBMS上对此进行建模. Faceted search just doesn’t work in a relational schema.
> IMO这不是代码生成的正确位置.您应该设计您的代码,以便它不会随着数据更改而改变(我不是在谈论架构更改).
>在Excel电子表格中存储元数据/属性似乎是一个非常糟糕的主意.我将构建一个用于编辑此UI的UI,它将存储在Solr / MongoDB / CouchDB /您选择管理它的任何内容中.
> Solr并不“仅镜像关系数据库”.事实上,Solr完全独立于关系数据库.最常见的情况之一是将数据从RDBMS转储到Solr(在流程中对数据进行非规范化),但Solr足够灵活,可以在没有任何关系数据源的情况下工作.
> Hierarchical faceting in Solr仍然是研究中的一个悬而未决的问题.目前正在研究两种不同的方法(SOLR-64,SOLR-792)
