I've been following the HABTM Railscast and am looking to extend it.
我一直在关注HABTM Railscast，我正在寻求扩展它。
The Railscast way is great for adding categories to a product. But lets say I have (say) 5 ways of categorising products along different dimensions (and these change occasionally).
Railscast方式非常适合在产品中添加类别。但是，让我说（我说）有5种方法可以按照不同的维度对产品进行分类（这些方法偶尔会有变化）。
With the solution provided I would need to add 2 more models to my app each time I add a new 'dimension'.
提供解决方案后，每次添加新的“维度”时，我都需要为我的应用添加2个模型。
Essentialy I want to move from a model like:
Essentialy我想从以下模型转移：
Product: Settlers of Catan
Categories: Board Games, Toys etc
产品：Catan的定居者类别：棋盘游戏，玩具等
to:
至：
Product: Settlers of Catan
Category: Board Games, Toy etc
Age Range, 1-10, 11-20
Cost: High
产品：Catan的定居者类别：棋盘游戏，玩具等年龄范围，1-10,11-20成本：高
The Railscast solution is here: http://railscasts.com/episodes/17-habtm-checkboxes-revised?view=comments
Railscast解决方案在这里：http：//railscasts.com/episodes/17-habtm-checkboxes-revised?view=comments
The existing solution, to be extended:
现有解决方案，待扩展：
Product.rb
Product.rb
has many categorisations
has many categories, through categorisations
Categorisation.rb
Categorisation.rb
belongs to many products
belongs to many categories
Category.rb
Category.rb
has many products, through categorisation
has many categorisations
I could do something like:
我可以这样做：
Product.rb
Product.rb
has many AgeRangeCategorisations
has many AgeRanges, through AgeRangeCategorisations
AgeRangeCategorisation.rb
AgeRangeCategorisation.rb
belongs to many products
belongs to many AgeRanges
AgeRange.rb
AgeRange.rb
has many products, through AgeRangeCategorisation
has many AgeRangeCategorisations
and
和
Product.rb
Product.rb
has many CostCategorisations
has many Costs, through CostCategorisations
CostCategorisation.rb
CostCategorisation.rb
belongs to many products
belongs to many costs
Cost.rb
Cost.rb
has many products, through CostCategorisation
has many CostCategorisations
But, it doesn't feel like the Rails way to create new models for each 'category type'.
但是，它并不像Rails那样为每个“类别类型”创建新模型。
I am think something along the lines of:
我想的是：
Product.rb
Product.rb
has many CategoryTypes
has many CategoryTypes, through CategoryTypeCategorisations
CategoryTypeCategorisations.rb
CategoryTypeCategorisations.rb
belongs to many Products
belongs to many CategoryTypes
CategoryType.rb
CategoryType.rb
belongs to many CategoryTypeCategorisations
belongs to many categorisations
has many categories, through categorisations
Categorisation.rb
Categorisation.rb
has many products
has many categories
Category.rb
Category.rb
has many products, through categorisation
has many categorisations
A CategoryType being the dimension (Age, Cost etc) and the category being the valid list of answers for the CategoryType.
CategoryType是维度（年龄，成本等），类别是CategoryType的有效答案列表。
This is getting a little confusing now with so many 'belongs to's and 'has many's floating about
现在这有点令人困惑，因为有很多'属于'并且有许多人在浮动
Is this the correct way to try to approach this issue? How else could I approach this?
这是尝试解决此问题的正确方法吗？我怎么能接近这个？
2 个解决方案
#1
0
Your last variant is one way to approach this. For sure you do not want a class for every category type. Unless maybe those category types come with a lot of extra business logic that defines how a product 'behaves', in which case something like Single Table Inheritance would be the better way to model this. But as you describe it I guess those are more like tags, mostly some additional description. (If there are only two or three category types and it stays that way, the number of classes won't matter that much, but if you plan more I would avoid this)
您的最后一个变体是解决此问题的一种方法。当然，您不希望每个类别类型都有一个类。除非这些类别类型带有许多额外的业务逻辑来定义产品的“行为”，在这种情况下，像单表继承这样的东西将是更好的模型化方法。但正如你所描述的那样，我猜这些更像是标签，大多是一些额外的描述。 （如果只有两个或三个类别类型，并且它保持这种方式，那么类的数量并不重要，但如果你计划更多，我会避免这种情况）
There would be one alternate option I want to mention at least for completeness and because it would save you one table and be less complex that way. This would be to model these categories simply as a hierarchy where your category types are parents and the categories are children.
至少在完整性方面我会提到一个备用选项，因为它会为你节省一张桌子并且不那么复杂。这可以将这些类别简单地建模为一个层次结构，其中您的类别类型是父类，类别是子类。
Category
- Board Games
- Toy
Age Range
- 1-10
- 11-20
Cost
- Low
- Medium
- High
This is more like a 'classical' approach to this problem.
这更像是解决这个问题的“经典”方法。
Also (especially if you have a lot of products and categories) maybe using some faceted search engine (Solr, Elastic, Sphinx...) or NOSql storage with similar abilities could make searching by several properties very easy.
另外（特别是如果你有很多产品和类别）可能使用一些分面搜索引擎（Solr，Elastic，Sphinx ......）或具有相似能力的NOSql存储可以使得几个属性的搜索变得非常容易。
#2
0
Use the postgres HStore data type as a column on the products model, and just add these things as key: value pairs.
使用postgres HStore数据类型作为产品模型上的列，只需将这些内容添加为键：值对。
#1
0
Your last variant is one way to approach this. For sure you do not want a class for every category type. Unless maybe those category types come with a lot of extra business logic that defines how a product 'behaves', in which case something like Single Table Inheritance would be the better way to model this. But as you describe it I guess those are more like tags, mostly some additional description. (If there are only two or three category types and it stays that way, the number of classes won't matter that much, but if you plan more I would avoid this)
您的最后一个变体是解决此问题的一种方法。当然，您不希望每个类别类型都有一个类。除非这些类别类型带有许多额外的业务逻辑来定义产品的“行为”，在这种情况下，像单表继承这样的东西将是更好的模型化方法。但正如你所描述的那样，我猜这些更像是标签，大多是一些额外的描述。 （如果只有两个或三个类别类型，并且它保持这种方式，那么类的数量并不重要，但如果你计划更多，我会避免这种情况）
There would be one alternate option I want to mention at least for completeness and because it would save you one table and be less complex that way. This would be to model these categories simply as a hierarchy where your category types are parents and the categories are children.
至少在完整性方面我会提到一个备用选项，因为它会为你节省一张桌子并且不那么复杂。这可以将这些类别简单地建模为一个层次结构，其中您的类别类型是父类，类别是子类。
Category
- Board Games
- Toy
Age Range
- 1-10
- 11-20
Cost
- Low
- Medium
- High
This is more like a 'classical' approach to this problem.
这更像是解决这个问题的“经典”方法。
Also (especially if you have a lot of products and categories) maybe using some faceted search engine (Solr, Elastic, Sphinx...) or NOSql storage with similar abilities could make searching by several properties very easy.
另外（特别是如果你有很多产品和类别）可能使用一些分面搜索引擎（Solr，Elastic，Sphinx ......）或具有相似能力的NOSql存储可以使得几个属性的搜索变得非常容易。
#2
0
Use the postgres HStore data type as a column on the products model, and just add these things as key: value pairs.
使用postgres HStore数据类型作为产品模型上的列，只需将这些内容添加为键：值对。