如何对“产品”进行建模 在在线商店应用程序中
我正在建立一家在线商店来销售“绿色超大 T 恤”等产品。 即，同一件衬衫可以有多种尺寸/颜色，不同的组合可以售完，不同的组合可能有不同的价格等。
我的问题是我应该如何在我的 Rails 应用程序中对这些产品进行建模（或者实际上如何在任何应用）。
我目前的想法是：
Class Product
has_many :variants, :through => :characteristics
has_many :characteristics
end
Class Characteristic
belongs_to :product
belongs_to :variants
end
Class Variant
has_many :products, :through => :characteristics
belongs_to :characteristic
end
因此，每种产品都会有一个或多个特征（例如，“颜色”、“尺寸”等），并且每个特征都会有一个或多个变体（例如，“红色”、“蓝色”等） ）。
此方法的问题是在哪里存储价格和库存？即，给定产品的价格和库存由其特性所采用的变体决定。 （绿色可能比红色贵，大的可能缺货，等等）。
我的一个想法是给产品一个“base_price”，并让变体修改它，但这似乎过于复杂（并且可能不起作用）。
I'm building an online store to sell products like "Green Extra-large, T-shirts". I.e., the same shirt can have many sizes / colors, different combination can be sold out, different combination might have different prices, etc.
My question is how I should model these products in my Rails application (or really how to do it in any application).
My current thinking is:
Class Product
has_many :variants, :through => :characteristics
has_many :characteristics
end
Class Characteristic
belongs_to :product
belongs_to :variants
end
Class Variant
has_many :products, :through => :characteristics
belongs_to :characteristic
end
So each product will have one or more characteristics (e.g., "Color", "Size", etc), and each characteristic will then have one or more variants (e.g., "Red", "Blue", etc).
The problem with this method is where do I store price and inventory? I.e., a given product's price and inventory are determined by the variants its characteristics take. (Green might be more expensive than red, large might be out of stock, etc).
One thought I had was to give products a "base_price", and let variants modify it, but this seems overly complex (and might not work).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我见过两种解决这种困境的方法。 首先是尝试使用特性来定义“主”产品的从属产品。 这里的挑战是，除了您目前的想法之外，在大多数情况下，产品还将随着新制造商的发展而发展，从而带来新的方面。 例如，一家制造商可能会生产一种更便宜的产品，但对徽标或缝线采用不同的应用方法，这些方法可能足够重要以进行跟踪。
我认为为每个产品携带一个不重要的产品编号，然后将特征附加为属性效果最好。 它易于搜索且可扩展。 如果一组产品密切相关，则单个产品附加到的 ProductGroup 效果很好。
在表中：
这里的优点是您可以轻松查询特定属性，属性是“灵活的”，因为可以添加更多属性（并且旧属性已调整：如果您从“红色”开始，然后向颜色添加另一个“红色”池，您可以将它们更改为“栗色”和“亮红色”，
您可以在详细产品级别控制价格和库存（尽管可能需要更多表格来计算采购成本）
< 。 strong>这一切都假设您的特征是普遍共享的。如果不是，您的特征子表方法可以通过在特征和产品详细信息表之间创建一个连接表并根据需要进行填充来工作，这将需要更多的业务逻辑。 .为了确保每个产品类别都具有必要的所有特征在后一种情况下，我将在基本产品表中使用“原型”产品（数量和成本为0），我将克隆该产品。特征，然后在输入每个新产品时进行调整。随着您的前进，当出现新的变体时，具有“克隆此产品”功能，允许您仅调整差异来自基础产品的价值将是有价值的。
最后，就管理库存和定价而言，这将发生在 UI 层。 能够生成相关产品（产品组）的查询并管理相关产品的所有定价将大大有助于使其变得宜居。
I have seen two solutions to this kind of dilemma. The first is to try to use characteristics to define subordinate products to the "main" product. The challenge here is that in addition to your thoughts for far, in most cases the product will evolve with new manufacturers that bring new aspects to the table. For example, one manufacturer may make a cheaper product, but have a different application method for the logo or stitching that may be significant enough to track.
I think that carrying a non significant product number for each product and then attaching the characteristics as attributes works out the best. It is easily searched and extensible. If a group of products are strongly related, a ProductGroup that the individual products attach to works well.
In tables:
The advantages here are that you can easily query for specific attributes, attributes are "flexible" in that more can be added (and old ones adjusted: if you started with "Red" but then added another "Red" to the color pool, you can change them to "Maroon" and "Bright Red".
You can control price and inventory are at the detail product level (although more tables may be required to account for sourcing costs).
This all assumes that your characteristics are universally shared. If they are not, your characteristic subtable approach can work by creating a join table between characteristics and the product detail tables and populate as needed. This will require more business logic .to ensure each product category gets all characteristics necessary. In this latter case I would use "prototype" products in the base product table (with Qty and Cost of 0) that I would clone the characteristics from and then adjust as each new product is entered. As you move forward, when a new variation appears, having a "clone this product" function that allows you to just adjust the differences from the base product would be valuable.
Finally, as far as managing the inventory and pricing, this is going to happen at the UI layer. Being able to generate queries for related products (product groups) and manage all the pricing for related products will go a long way to making this livable.
只是一个快速说明。 您可以随时尝试查看其他一些电子商务产品的源代码，例如 Spree 和 Substruct 他们可能已经为您回答了这个问题。
Just a quick-note. You can always try and take a look at the sourcecode of some other e-commerce products like Spree and Substruct they probably already answered that question for you.