一段时间以来，我一直在考虑如何使用类似于 eBay 的分类法和依赖于特定产品类别的属性来对典型的电子商务网站进行建模。
第一次尝试是在 EAV 和 Table Per Class 数据库继承建模之间进行选择。我选择后者是因为性能，但这意味着为每个特定（类别树中的叶子）产品类别创建专用表，并将特定类别属性（例如电视的分辨率）建模为单独的列。
虽然性能良好，但如果您需要向现有类别添加属性或添加新类别，则此设置并不灵活。对于每个此类更改都需要以下内容：
- 更改/创建表
- 用于按特定属性过滤此类类别的新表单
- 用于生成用于搜索和过滤的数据库查询的新代码
- 一些新的视图模型/DTO 和用于展示新类别产品的视图
为了应对这种复杂性，我认为需要在 xml 甚至 excel 文件中对这些属性进行某种元表示（甚至在应用程序之外），以便在每次更改时都可以自动生成所有提到的代码（sql/orm 查询、应用程序代码、模板）。因此它可以帮助开发，但仍然需要测试和额外的部署。
那时我了解到 eBay 并没有真正使用关系数据库进行搜索，而且他们的分类非常灵活，他们可以很快添加新的叶类别。此外，它们的类别可能不是来自关系数据库中建模的分层树的类别，而只是搜索属性（方面）。
在快速浏览了最有前途的专用分面搜索设置（单独的 Solr 实例）后，我不确定它是否可以帮助我灵活地应对分类法更改，因为通常 Solr 只是以某种方式镜像关系数据库，因此特定类别属性仍然必须在数据库中建模为 DBMS 元数据，因此例如。动态生成用于过滤属性的 UI 表单将很困难，除非：
1）我将使用EAV fasion将数据保存在RDBMS中，并使用SOLR搜索克服其性能问题（但仍然存在EAV混乱、没有数据完整性强制等问题）
2）我将只在 RDBMS 中保留属性字典（即仅保留它们的名称和类型），并将特定属性值存储在 SOLR 中，将其用作除搜索工具之外的非关系数据存储。我也不相信这个解决方案（即使可能），因为应用程序将与 solr 紧密耦合（即产品版本管理 CRUD 将直接与 SOLR 交互）。
你怎么看？您认为对于任何类型的此类（高性能）分类法灵活性，代码生成都是不可避免的吗？你会怎么处理？也许数据库中 EAV 风格的一些单独的数据字典只是用于代码生成目的？我想我也可以使用 MongoDB 之类的东西，但 UI 代码生成（运行时或非运行时）仍然需要某种元数据。
这里有很多问题，但我不想将其分解为更小的问题，因为我对处理更大类此类问题时的通用设计方法感兴趣。
