如果不更清楚地了解您的业务逻辑,我认为这个问题很难回答。以下是我的假设:
- 可配置选项是临时性的,即您出售红色、蓝色和黄色的球,以及小、中、大号的衬衫等。这些选项没有办法抽象地表示,因为它们不超越类别。(如果他们这样做了,那么您的数据库设计就是错误的。如果所有内容都有自定义颜色选项,您只需在数据库表中将其设为一列。)
- 每个配置选项在您的公司都有一个预先存在的业务标识。有一些 sku 与红球或类似的东西有关。无论出于何种原因,每个可能的配置选项都必须有一个数据库行。(如果不是,那么你又做错了。)
如果是这种情况,我最简单的建议是拥有一些所有产品都继承自一个字段的基类:representative_product_id
. 这个想法是,对于每个产品,都有一个代表版本显示在类别页面或目录中的任何其他位置。在您的数据库中,这将如下所示:
Name id representative_id
red_ball 1 1
blue_ball 2 1
green_ball 3 1
small_shirt 4 4
medium_shirt 5 4
large_shirt 6 4
unique_thing 7 7
至于 django 查询,F objects
如果您有 1.1 或更高版本,我会使用。只是:
SimpleProduct.objects.filter(representative_id=F('id'))
这将返回一个查询集,其代表 id 与他们自己的 id 匹配。
此时,有人会叫嚣数据的完整性。主要条件是representative_id
在所有情况下都必须指向与其representative_id
匹配的对象id
。有一些方法可以直接执行此操作,例如使用pre_save
验证器或类似的东西。ProductType
您也可以通过分解包含representative_id
列的表来有效地做同样的事情。IE:
Products
Name id product_type
_________________________________
red_ball 1 ball
blue_ball 2 ball
green_ball 3 ball
small_shirt 4 shirt
medium_shirt 5 shirt
large_shirt 6 shirt
unique_thing 7 thing
Types
Name representative_id
_______________________________
ball 1
shit 4
thing 7
这并不能取代使用某些验证器来强制执行完整性的需要,但它使它更加抽象。