问个数据库设计问题，比如课程有单课程和组合课程（每个组合课程有多个单课程组成，单课程有交叉）

[baleeny]

单课程和组合课程（每个组合课程有多个单课程组成，单课程有交叉） 而这些课程又会根据上课地点，时间，年龄等条件生成不同的商品 这个表应该怎么设计好点。数据库是 postgresql

谢谢各位答疑解惑，不一一回复了，感谢

[pengtdyd]

子关联+一对多

[baleeny]

@pengtdyd 课程表，课程关联表，课程商品表、课程商品关联表，这个样子？

[kkeep]

单课程交叉是什么意思，

组合课程的有单独的上课地点么，是以哪个为准？可以并行上课么？

等等很多问题，要问的细一点才能做决定

[sy20030260]

如果是商品的话核心是价格和库存吧。描述得不太清楚，但我理解产品形态应该类似一个课程商城，点击某个课程进入详情页之后可以选择上课地点、时间、年龄然后匹配不同的价格下单？

如果是这样直接参考电商商品的数据库设计，一个课程是一个 SPU ，上课地点 /时间 /年龄等相当于商品属性，每一个固定商品属性排列组合对应一个 SKU ，不同 SKU 对应不同价格、库存

[baleeny]

@kkeep 就是单课程可能在多个组合课程里出现

[baleeny]

@sy20030260 差不多是按这个思路走的，就是组合商品这块不知道怎么设计好点，组合课程里有多个课程，到商品这块排列组合就有点不知所措了 0.0 ，每一个课程可能出现在多个组合课程里价格还不一样。

[baleeny]

@kkeep 就是你楼下说的上课地点时间年龄是属性，在组合课程里每一个课程都可以单独选，就是类似买个套装可以便宜，属性交叉出来的唯一商品都有类似库存限制，也不存在什么并行上课。

[kkeep]

对，课程跟 sku 是两个东西

[sy20030260]

@baleeny 主要看组合课程是否是独立计算库存，以及后台的上架逻辑是怎样的。看你说组合课程价格还不一样，猜测组合课程后台是一套独立的上架流程，然后库存也是独立的？如果都是独立的那就比较简单，可以把组合课程当作一种特殊 SPU 处理就行。如果库存不是独立的只是价格不一样，建议做到下单逻辑那边好一点，不要做在商品和 SKU 这边。大概可以理解成组合下单的价格优惠逻辑，实际下单还是多个 SPU ，识别到固定的 SPU 组合就做个减价就行。不过核心还是得看组合课程的后台上架逻辑是怎样的

[wangritian]

1.课程表
2.课程组合表 为了简化逻辑，单课程也算一个组合
3.组合与课程关联表 一对多
4.商品表 时间，年龄，组合 id

[akira]

组合课程里面 的 优惠价格是怎么算的，这块业务逻辑先梳理清楚啊

[Chad0000]

可以分为课程和上课，前者定义课程，后者用来排课（上课），一对多。即使单课的也需要创建上课。

[xuanbg]

课程表（单课程）/课程商品表（课程组合，单课程也算组合）/商品-课程关系表

[xuanbg]

课程这东西和普通商品不太一样，既有数量限制（教室容量），有没有数量限制（这一节课约不上可约下一节课）。所以可以在销售时完全不考虑库存，售后通过预约系统来预约上课就行。就是铁打的课程（哪个老师在哪个教室上什么课，都可以预先排出计划）流水的学生（预约到的就来上课）。

[baleeny]

@sy20030260 非常感谢，组合课程库存不是独立的，根据你的建议放到下单逻辑那块挺合适，我也可以把组合课程弄成一个特殊的 SPU 用作展示吧（这样是不是就不需要课程关联表了，直接一个课程表，多加一个子课程数组字段。），因为这个组合课程有单独的名称和描述等 0.0

[sy20030260]

@baleeny 嗯，主要还是看组合课程在后台怎么上架，以及在 C 端怎么展示 /怎么检索。如果组合课程的上架逻辑 /展示逻辑 /检索逻辑等都和单课程商品的类似，那把它设计成一个特殊 SPU 是合适的，这样可以最大程度复用原有逻辑；反过来如果这些逻辑都不太一样，就没必要强行抽象成一个 SPU 了，把这个逻辑解耦反而更干净一点。反正只要能满足价格和库存逻辑上的需求，其他展示啥的都是次要问题了，选择相对舒服和干净的实现方式即可

[baleeny]

@sy20030260 感谢解答，谢谢

[baleeny]

@xuanbg 你这个逻辑很好，感谢回复，没准后续会往这个方向发展，现在还不太需要.