logoChat01.ai

PMS SKU Stock解析

Erstellt am: 7. Februar 2025

Beantwortet mit GPT-4o von Chat01

Frage

creat-mall.txt

讲讲pms_sku_stock表吧，该怎么从业务层面理解这个表、表字段、以及这个表与其他表的关联关系？

Antwort

pms_sku_stock 表解析

1. 业务层面理解

pms_sku_stock 表主要用于存储商品 SKU（Stock Keeping Unit，库存单位）的库存信息。在电商系统中，商品（Product）通常有不同的规格（如颜色、尺码等），每个规格组合对应一个 SKU。因此，该表的主要作用是：

  • 记录每个 SKU 的库存情况
  • 支持库存管理（包括锁定库存、预警库存等）
  • 关联商品价格和促销价格
  • 追踪 SKU 的销量

在业务流程中，该表通常用于：

  • 下单时校验库存
  • 订单支付后扣减库存
  • 订单取消/退款时释放库存
  • 商品详情页展示不同 SKU 价格和库存
  • 促销活动中的 SKU 价格调整

2. 表字段解析

pms_sku_stock 表的字段如下：

字段名数据类型说明
idbigint(20)主键，自增
product_idbigint(20)关联 pms_product 表，表示该 SKU 属于哪个商品
sku_codevarchar(64)SKU 编码，唯一标识 SKU
pricedecimal(10,2)SKU 的原价
stockint(11)SKU 的可用库存数量
low_stockint(11)预警库存，当库存低于该值时，可能会触发预警通知
picvarchar(255)SKU 关联的展示图片
saleint(11)该 SKU 的销量
promotion_pricedecimal(10,2)SKU 在促销活动中的价格（如果有促销）
lock_stockint(11)锁定库存（如：待付款订单锁定的库存，支付完成才扣减）
sp_datavarchar(500)商品销售属性（JSON 格式），用于描述该 SKU 的规格，如 {"颜色":"红色", "尺码":"L"}

3. 该表与其他表的关联

pms_sku_stock 表主要和以下表有外键关系：

  1. 商品表 pms_product

    • 通过 product_id 关联，表示该 SKU 属于哪个商品
    • 例如：pms_product 表中可能有 "Nike 运动鞋"，而 pms_sku_stock 可能有 "Nike 运动鞋（黑色，42码）"、"Nike 运动鞋（白色，41码）" 等 SKU

  2. 购物车表 oms_cart_item

    • product_sku_id 关联 pms_sku_stock 表的 id
    • 购物车中存储用户添加的具体 SKU 信息
    • 例如：用户在购物车中选择的是 "Nike 运动鞋（黑色，42码）"

  3. 订单项表 oms_order_item

    • product_sku_id 关联 pms_sku_stock 表的 id
    • 订单确认后，库存需要锁定并在支付完成后扣减库存
    • 例如：用户下单了一双 "Nike 运动鞋（黑色，42码）"，支付后该 SKU 的 stock 减少 1

  4. 促销表 sms_flash_promotion_product_relation

    • product_id 关联 pms_product，并可能涉及 pms_sku_stock
    • 促销活动可能会针对某些 SKU 设置特价，影响 promotion_price 字段

4. 业务应用场景

（1）库存管理
  • 当用户下单时，先检查 stock 是否足够，再扣减 lock_stock
  • 订单支付成功后，真正扣减 stock
  • 订单取消或退款时，释放 lock_stock
（2）促销活动
  • 促销时，可以更新 promotion_price 字段
  • 例如：Nike 运动鞋（黑色，42码） 原价 ¥499，促销价 ¥399
（3）预警通知
  • 当 stock 低于 low_stock 时，触发库存预警
  • 例如：Nike 运动鞋（黑色，42码） 低于 5 件，通知补货
（4）展示 SKU 信息
  • 商品详情页根据 pms_sku_stock 的 sp_data 显示不同规格的 SKU
  • 例如："颜色：黑色 / 白色"，"尺码：41 / 42 / 43"

5. 总结

  • pms_sku_stock 负责管理 SKU 级别的库存、价格、促销等信息
  • 该表与 pms_product（商品）、oms_cart_item（购物车）、oms_order_item（订单项）等表紧密相关
  • 业务流程中涉及下单、支付、退款、促销等环节
  • 通过 lock_stock 机制避免超卖，low_stock 机制实现库存预警

这个表是电商系统中至关重要的库存管理核心，影响整个库存调度和订单履约流程。

Frage

sku_code、sale、promotion_price、lock_stock这几个字段我没接触过，不太了解

Gedanke

Reasoned about SKU表字段含义，持续 几秒

Antwort

在电商后台管理中，pms_sku_stock 里面的字段可能有些在实际场景中使用频率较高，有些则是为更灵活的业务需求做的预留。下面从业务和实际使用层面，分别阐述一下 sku_code、sale、promotion_price、lock_stock 这几个字段的含义与作用。

1. sku_code

1.1 字段含义

  • 字段类型：varchar(64)（或类似长度）
  • 可能的命名：SKU 编码、SKU 标识
  • 业务含义：
    sku_code 通常是SKU 在业务或仓储系统中的唯一识别码，用于区分不同的 SKU。
    在一些系统中，sku_code 也会用来与线下或第三方仓储系统进行对接，因为仓库通常使用 SKU 编码来定位和出入库。

1.2 业务场景

  1. 仓库对接：
    如果需要将库存数据同步到第三方仓储，或在 ERP（企业资源规划）系统中做出入库、盘点操作，可以通过 sku_code 对应到仓库系统里的 SKU 代码。
  2. 商品管理：
    后台或运营人员在搜索某个商品的某个 SKU 时，有时会直接使用 sku_code 进行精确查找。

1.3 注意事项

  • sku_code 在同一个商品体系里要保证全局或至少商品维度唯一，否则会造成数据混乱。
  • 一般的做法是，在电商平台上对于同一商品的不同规格组合，生成对应的 sku_code。有些公司会用流水号或规则编码自动生成（如 “SKU_商品ID_颜色_尺码_随机码” 之类）。

2. sale

2.1 字段含义

  • 字段类型：int(11)（或整型）
  • 可能的命名：销量、累计销售量
  • 业务含义：
    sale 一般代表该 SKU 的累计销售量或销量统计，用于展示、统计或做营销决策。

2.2 业务场景

  1. 前台展示：
    一些电商网站会显示 “已售出多少件”，来做销量展示，增加用户购买信心。
  2. 销售统计：
    运营或财务人员可能会根据这个字段统计当下最畅销的 SKU，或者对比分析同一个商品不同规格的销量差异。
  3. 营销策略：
    • 运营人员可能会优先推广销量较高的 SKU（因为畅销 SKU 通常转化率更好）。
    • 对销量不佳的 SKU 做促销或清仓处理。

2.3 注意事项

  • 系统里需要在订单完成后（例如订单状态为已发货、确认收货等），更新或累加该字段，确保统计的真实性。
  • 如果订单取消或退款，部分系统也会相应减去销量，具体看业务规则。

3. promotion_price

3.1 字段含义

  • 字段类型：decimal(10,2)（或类似精度的小数）
  • 可能的命名：促销价、活动价格
  • 业务含义：
    promotion_price 表示SKU 在促销或活动期间的售价。当有优惠活动时，通常会将商品临时以折扣价对外显示和售卖。

3.2 业务场景

  1. 限时折扣：
    在进行限时秒杀或满减促销活动时，将 SKU 的促销价赋值到 promotion_price，前端在活动时间内优先展示 promotion_price 而不是 price。
  2. 活动管理：
    不同促销活动的价格可能会写入这个字段。如抢购活动价、拼团价等。不过也有些系统会将促销价放在活动单独的关联表中，根据活动 ID 进行映射，具体根据业务设计而定。
  3. 价格显示逻辑：
    • 如果 promotion_price 有值且活动进行中，则页面会显示促销价；若促销结束或 promotion_price 为空，则显示原价 price。
    • 有些平台会显示原价划线价 + 促销价双价展示。

3.3 注意事项

  • promotion_price 是否一定要存储在 pms_sku_stock 里，或者存储在哪个促销专用表里，需要结合系统设计考虑。如果活动很多，可能会使用更灵活的方式去记录，而不是直接写在 SKU 表里。
  • 注意促销的时间段管理：仅在促销有效期内使用 promotion_price 做交易结算，过期或提前结束后必须恢复原价。

4. lock_stock

4.1 字段含义

  • 字段类型：int(11)（或整型）
  • 可能的命名：锁定库存、占用库存
  • 业务含义：
    lock_stock 用于记录正在被“锁定”的库存数量。通常在下单环节或活动预留库存时，会先锁定库存，等真正支付完成后再扣减实际库存。

4.2 业务场景

  1. 下单锁库：
    用户在电商平台下单时，如果不立刻支付，在生成订单后，需要从 stock 里扣除一部分放到 lock_stock 中，代表已被这笔订单占用，避免其他用户重复购买导致超卖。
  2. 支付/取消：
    • 当订单支付成功，系统会正式减掉库存 stock，并且相应地减少 lock_stock。
    • 如果订单未支付超时取消或用户主动取消，这个订单对应的“锁定库存”就要释放回到 stock 里去。
  3. 大促销活动防超卖：
    当有大规模秒杀或预售，锁库逻辑更为关键；秒杀系统一般会通过修改 lock_stock 或其他“占用库存”字段来保障不会超卖。

4.3 注意事项

  • 需要与订单状态或支付状态及时联动更新：
    • 下单成功且支付中，先增加 lock_stock；
    • 支付成功后，真正扣减 stock；
    • 订单关闭或支付失败释放 lock_stock。
  • 如果系统处理不及时或者并发量大，可能出现“锁库没释放”或“库存没有真正扣减”的问题，需要在业务流程和事务处理上做好设计。

5. 总结

  • sku_code：SKU 的唯一识别码，便于库存、仓储、订单系统进行对接或定位
  • sale：累计销量统计字段，可用于前台展示及后台运营决策
  • promotion_price：在促销活动或优惠期间所使用的价格
  • lock_stock：订单下单后锁定的库存量，用于防止并发购买时的超卖问题

这四个字段体现了一个电商平台在SKU 管理、库存管理、营销活动管理和销售统计方面的基本需求与流程。在实际开发中，需要结合订单、支付、库存扣减等核心链路，才能让这些字段真正发挥作用。

Frage

lock_stock这块到底怎么操作你没说清楚啊兄弟，用一些具体的例子吧，我这里也有数据库表中的数据做参考：

98 27 201808270027001 2699.00 86 -24 [{"key":"颜色","value":"黑色"},{"key":"容量","value":"32G"}]
99 27 201808270027002 2999.00 100 0 [{"key":"颜色","value":"黑色"},{"key":"容量","value":"64G"}]

你看着来吧

Gedanke

审视库存数据

我正在看一个关于库存的数据表，看到一列可能是 "lock_stock"，发现数据中的负值令人好奇。

理解库存锁定

首先，库存锁定通常是非负的，而数据中的负值可能说明了超卖或支付不成功的情况。这让我想到库存管理的重要性。

探讨库存锁定

首先，用户选择了3件商品，我们要查看库存是否足够。现在的-24值可能表示库存借用或超卖，这让我想到库存管理的复杂性。

追踪库存变动

库存从86减至83处理订单，锁定库存从3变为0。如果订单取消或未支付，将撤销这些变化。这种管理方法让我想到库存动态的复杂性。

Razonado sobre el campo lock_stock，持续 20 秒

Antwort

下面给你一个逐步、场景化的例子，帮你理解实际业务中 lock_stock（锁定库存）是怎么操作的，以及为什么有时会出现看似“奇怪”的数值（例如负数）。

一、先看你给出的数据

你给出了两行示例数据（字段取决于你的表结构，以下仅根据你提供的信息做推测）：

idproduct_idsku_codepricestocklock_stocksp_data
98272018082700270012699.0086-24[{"key":"颜色","value":"黑色"},{"key":"容量","value":"32G"}]
99272018082700270022999.001000[{"key":"颜色","value":"黑色"},{"key":"容量","value":"64G"}]

从这儿可以看出两个 SKU（都是 product_id = 27 的同一个商品的不同规格）：

  1. SKU1（id=98）：32G，当前 stock=86，lock_stock=-24
  2. SKU2（id=99）：64G，当前 stock=100，lock_stock=0

其中，SKU2 的 lock_stock=0 很常见，表示目前没有被下单占用的库存；但 SKU1 出现了 lock_stock=-24，就比较特殊或“诡异”了，按正常逻辑，锁定库存一般不会为负。

我们先简单回顾一下“正常的”锁库流程是什么样的，随后再讨论为什么会出现负数。

二、正常锁库流程（理想情况下）

2.1 下单时

  1. 用户在前台提交订单：
    • 假设用户要买 3 个“黑色 32G”这个 SKU。
    • 业务逻辑先判断：当前 stock >= 3 吗？如果够，就把这 3 个“暂时锁定”，以防止别人再买走。
  2. 更新库存表：
    在订单产生（但还未支付）时，通常会：
    • 增加 lock_stock 的值（+3）
    • 也可以选择同时减少 stock，或者把 stock 保持原样，仅用 lock_stock 来标识“被占用”的量——不同项目对字段意义可能略有差异。
    常见做法是：
    • stock 只记录“可售库存”剩余量，而“锁定库存”用 lock_stock 记录。
    • 或者 stock 记录“理论总库存”，lock_stock 记录已被锁的。无论哪种，都不应该出现负数锁定。
  3. 举例：
    • 原来 stock=86, lock_stock=0。
    • 用户买了 3 个，那么锁定 3 个库存：
      • stock 可能保持 86 不变，lock_stock 变成 3；
      • 或者 stock 直接改为 83，lock_stock 变为 3；要看具体项目如何定义字段含义。

2.2 订单支付/取消时

  • 支付成功：
    • 在实际业务中，会把“锁定的 3 个”真正从总库存里减掉；如果 stock 在下单时未减过，这时就 stock = 86 - 3 = 83，lock_stock = 0（释放占用）
    • 如果在下单时已经把 stock 减到 83，只是还在 lock_stock 里标记 3，那么支付成功后，一般就把 lock_stock 清零即可。
  • 订单取消（超时未支付、用户主动取消等）：
    • 被“锁定”的库存要释放回可售库存：
    • 如果 stock 未扣减过，那么 lock_stock 减 3，stock 保持不变；
    • 如果 stock 在下单时就减掉了，那就要把 stock +3 回到 86，lock_stock 减到 0。

三、为什么会出现 lock_stock = -24？

在理想的锁库逻辑里，lock_stock 应该始终是一个大于等于 0 的数，因为它表示“被占用、锁住”的数量。出现 -24 一般可能是以下几种原因：

  1. 数据紊乱或更新顺序问题
    • 某些逻辑写法：先扣减了 lock_stock，还没来得及把 stock 增回来，就被其他流程打断或出现异常，导致 lock_stock 累减到负数。
  2. 库存字段含义混淆
    • 项目中把 stock 当作“理论库存”，而把 lock_stock 当作“实际可售库存 - 理论库存”的“差额”之类的含义，用法不一致。
    • 比如有人把 lock_stock 用来记“超卖”多少，正数或负数表示一种补偿量、差额量。
  3. 历史数据遗留/手工修改
    • 运维或者运营人员直接在数据库手动改数据时输错了，造成负值。
    • 或者有批量清理脚本误把 lock_stock 扣成了负数。
  4. 特殊业务场景：后置同步
    • 可能跟仓库系统做了对接，仓库反馈“少了 24 件”，或者“已经售出 24 件，但系统没及时更新 stock”，某些同步逻辑把这 24 件错误地记录在 lock_stock 里，从而出现负数。

在大部分电商主流做法中，很少会直接把 lock_stock 设为负数，因为从名称和常识上看，“锁定”本身就不应该是负的；但在有些系统里，他们的 stock、lock_stock 字段不完全按“可售库存 + 锁定库存”的思路来用，而是作为差异值或“校正值”。这就导致你看到的 lock_stock = -24。

四、举一个“带负数”情景的例子

假设在某些项目里，他们定义了如下计算公式：

可用库存 = stock + lock_stock
  • 这里 stock 可能指“理论库存”或“原始库存”，
  • 而 lock_stock 则是一个“校正量”（正数表示还可以用多少，负数表示超卖或需要补多少）。

那么，如果 stock=86，lock_stock=-24，意味着：

可用库存 = 86 + (-24) = 62

也就是系统当前真正可卖的只有 62 件。
把 -24 理解为：“这 24 个是已经超卖了，需要补回”。或是“已经被订单占用，超出了某个基准值”。

4.1 例子流程

  1. 最开始 stock=86, lock_stock=0, 可卖 = 86。
  2. 突然来了一波秒杀，下了 50 个订单（每个订单买 1 件），但是我们只及时更新了 “实际可卖” 的字段（可卖 = 36），并且把差额记录在 lock_stock。
  3. 如果团队的做法是：lock_stock = “可用库存 - 原始库存” = 36 - 86 = -50（举例）。
    • 这样就出现了 lock_stock 是 -50 的情况。
  4. 之后有 26 个订单又被取消了，系统把可卖库存恢复到 62，那么 lock_stock 也就变成 -24，表示还在被占用或者超卖的量是 24。

总之，这种“带负数”的用法是把 lock_stock 当作修正量而非简单的“锁住的数量”。

五、给你一个更直观的操作思路

如果你想要实现**正常的“锁库 + 释放 + 扣减”**逻辑，通常会这样做（不出现负数）：

  1. 初始：

    • stock=86, lock_stock=0，可售=86

  2. 用户下单（比如 5 件）：

    • 检查 stock 是否>= 5
    • 如果够用，则：
      • lock_stock += 5 ( lock_stock = 5 )
      • 同时 stock -= 5 ( stock = 81 )
    • （或者也有项目只改 lock_stock，不改 stock，看具体业务定义）

  3. 订单支付成功：

    • 订单算是成交，这 5 件要真正扣减库存
    • 如果你在“下单时”就把 stock 改到 81，那么就只需要 lock_stock -= 5 = 0。
    • 如果你在“下单时”没改 stock，而是只给 lock_stock=5，那此刻就要真正 stock -= 5 = 81，并 lock_stock 回到 0。

  4. 订单取消：

    • 把“下单时”占用的 5 件释放回 stock。
    • 如果“下单时”是 stock=86 → 81，那就此刻 stock=81+5=86，lock_stock=0。
    • 如果“下单时”只改 lock_stock=5, 没动 stock，那现在只需要 lock_stock=0 并保持 stock=86。

通过以上步骤，就可以很清晰地做到不出现锁定库存为负数。

六、总结

  1. “常规”做法：

    • lock_stock 表示锁住的库存数，通常应 >= 0。
    • 订单下单时锁住库存、支付成功后实际扣减库存、订单取消时释放库存。

  2. 你表中 lock_stock=-24 的可能原因：

    • 这在“常规锁库逻辑”中并不正常，常见于数据紊乱、特殊业务定义或人工干预等情况。
    • 某些团队把 lock_stock 当“差异量”或“超卖校正量”来使用，从而出现负数。

  3. 如何修正或理解现状：

    • 先搞清楚项目里到底是如何定义 stock、lock_stock、以及“可用库存=?” 的算法。
    • 如果确实要保持常规逻辑，建议把 lock_stock 只用于“锁定的量”并确保其非负，把库存超卖、差异同步等逻辑放在别的字段或别的机制里处理。
    • 如果这是“遗留数据”，需要手工或批量脚本来修正负数，避免下次业务再出错。

总之，从你的示例可以推测，要么是“表中字段混用了其他含义”，要么是“系统曾经出现过异常或人工数据修改”。如果你们想把库存逻辑做得更“干净可控”，就最好遵循“锁定库存 = 正数”并配合清晰的加减流程，这样在查问题或扩展功能时更容易追踪。

Diesen Q&A teilen