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