单课程和组合课程（每个组合课程有多个单课程组成，单课程有交叉） 而这些课程又会根据上课地点，时间，年龄等条件生成不同的商品 这个表应该怎么设计好点。数据库是 postgresql
This topic created in 1528 days ago, the information mentioned may be changed or developed.
Supplement 1 · Aug 29, 2022
谢谢各位答疑解惑，不一一回复了，感谢
 |
pengtdydAug 28, 2022
1
子关联+一对多
|
 |
kkeepAug 28, 2022 via Android
3
单课程交叉是什么意思，
组合课程的有单独的上课地点么，是以哪个为准？可以并行上课么？ 等等很多问题，要问的细一点才能做决定 |
 |
4
如果是商品的话核心是价格和库存吧。描述得不太清楚，但我理解产品形态应该类似一个课程商城，点击某个课程进入详情页之后可以选择上课地点、时间、年龄然后匹配不同的价格下单？
如果是这样直接参考电商商品的数据库设计，一个课程是一个 SPU ，上课地点 /时间 /年龄等相当于商品属性，每一个固定商品属性排列组合对应一个 SKU ，不同 SKU 对应不同价格、库存 |
1 |
6
@sy20030260 差不多是按这个思路走的，就是组合商品这块不知道怎么设计好点，组合课程里有多个课程，到商品这块排列组合就有点不知所措了 0.0 ，每一个课程可能出现在多个组合课程里价格还不一样。
|
|
7
@kkeep 就是你楼下说的上课地点时间年龄是属性，在组合课程里每一个课程都可以单独选，就是类似买个套装可以便宜，属性交叉出来的唯一商品都有类似库存限制，也不存在什么并行上课。
|
|
kkeepAug 29, 2022 via Android
8
对，课程跟 sku 是两个东西
|
|
sy20030260Aug 29, 2022
9
@baleeny 主要看组合课程是否是独立计算库存，以及后台的上架逻辑是怎样的。看你说组合课程价格还不一样，猜测组合课程后台是一套独立的上架流程，然后库存也是独立的？如果都是独立的那就比较简单，可以把组合课程当作一种特殊 SPU 处理就行。如果库存不是独立的只是价格不一样，建议做到下单逻辑那边好一点，不要做在商品和 SKU 这边。大概可以理解成组合下单的价格优惠逻辑，实际下单还是多个 SPU ，识别到固定的 SPU 组合就做个减价就行。不过核心还是得看组合课程的后台上架逻辑是怎样的
|
 |
WaldenHorizonAug 29, 2022
10
1.课程表
2.课程组合表 为了简化逻辑，单课程也算一个组合 3.组合与课程关联表 一对多 4.商品表 时间，年龄，组合 id |
 |
akiraAug 29, 2022
11
组合课程里面 的 优惠价格是怎么算的，这块业务逻辑先梳理清楚啊
|
 |
ktqFDx9m2Bvfq3y4Aug 29, 2022 via iPhone
12
可以分为课程和上课，前者定义课程，后者用来排课（上课），一对多。即使单课的也需要创建上课。
|
 |
xuanbgAug 29, 2022
13
课程表（单课程）/课程商品表（课程组合，单课程也算组合）/商品-课程关系表
|
|
xuanbgAug 29, 2022
14
课程这东西和普通商品不太一样，既有数量限制（教室容量），有没有数量限制（这一节课约不上可约下一节课）。所以可以在销售时完全不考虑库存，售后通过预约系统来预约上课就行。就是铁打的课程（哪个老师在哪个教室上什么课，都可以预先排出计划）流水的学生（预约到的就来上课）。
|
|
15
@sy20030260 非常感谢，组合课程库存不是独立的，根据你的建议放到下单逻辑那块挺合适，我也可以把组合课程弄成一个特殊的 SPU 用作展示吧（这样是不是就不需要课程关联表了，直接一个课程表，多加一个子课程数组字段。），因为这个组合课程有单独的名称和描述等 0.0
|
|
sy20030260Aug 29, 2022
16
@baleeny 嗯，主要还是看组合课程在后台怎么上架，以及在 C 端怎么展示 /怎么检索。如果组合课程的上架逻辑 /展示逻辑 /检索逻辑等都和单课程商品的类似，那把它设计成一个特殊 SPU 是合适的，这样可以最大程度复用原有逻辑；反过来如果这些逻辑都不太一样，就没必要强行抽象成一个 SPU 了，把这个逻辑解耦反而更干净一点。反正只要能满足价格和库存逻辑上的需求，其他展示啥的都是次要问题了，选择相对舒服和干净的实现方式即可
|
|
17
@sy20030260 感谢解答，谢谢
|
Select Language