43 lines
2.2 KiB
MySQL
43 lines
2.2 KiB
MySQL
|
-- =============================================================================
|
|||
|
|
-- 扫码草稿表（scan_draft）
|
|||
|
|
--
|
|||
|
|
-- 背景
|
|||
|
|
-- 扫码出库/借库的作业过程可能很长（一张单几十项），工人常需中途暂停去处理
|
|||
|
|
-- 更紧急的单据。改造前切换单据会直接清空已扫内容，刷新/退出页面更是全部丢失。
|
|||
|
|
--
|
|||
|
|
-- 库存已在申请审批通过时**预占**，暂停期间不会被他人抢走 —— 因此草稿只需
|
|||
|
|
-- 记录「扫到哪了」，不涉及任何库存操作，纯状态保存。
|
|||
|
|
--
|
|||
|
|
-- 隔离粒度：(user_id, biz_type, request_id)
|
|||
|
|
-- 一人一单 —— 每个人扫自己的草稿，互不影响；同一人可同时持有多张单据的草稿。
|
|||
|
|
--
|
|||
|
|
-- 为什么整单存一个 JSON（而非每条明细一行）
|
|||
|
|
-- 1. 保存是「全量覆盖」语义，逐行存并无增量更新的收益；
|
|||
|
|
-- 2. 恢复时需要物料名称/规格/库位等展示字段，逐行存方案只能回查申请单
|
|||
|
|
-- 的 items_json —— 而历史单据的 items_json 不含 stock_id，回查会错配。
|
|||
|
|
-- 整单快照把展示字段一并存下，恢复时零依赖、对老单据同样可靠。
|
|||
|
|
--
|
|||
|
|
-- 执行: docker exec -i inventory_db psql -U test -d inventory_system < 本文件
|
|||
|
|
-- =============================================================================
|
|||
|
|
BEGIN;
|
|||
|
|
|
|||
|
|
DROP TABLE IF EXISTS scan_draft;
|
|||
|
|
|
|||
|
|
CREATE TABLE scan_draft (
|
|||
|
|
id SERIAL PRIMARY KEY,
|
|||
|
|
user_id integer NOT NULL,
|
|||
|
|
biz_type varchar(20) NOT NULL, -- outbound / borrow
|
|||
|
|
request_id integer NOT NULL, -- 关联的申请单ID
|
|||
|
|
request_no varchar(100), -- 单号快照，便于展示免联表
|
|||
|
|
-- 整单快照：[{stock_id, source_table, sku, name, spec_model,
|
|||
|
|
-- warehouse_location, available_quantity, out_quantity, price}, ...]
|
|||
|
|
items_json jsonb NOT NULL DEFAULT '[]'::jsonb,
|
|||
|
|
updated_at timestamp without time zone NOT NULL DEFAULT timezone('Asia/Shanghai', now()),
|
|||
|
|
created_at timestamp without time zone NOT NULL DEFAULT timezone('Asia/Shanghai', now()),
|
|||
|
|
CONSTRAINT uq_scan_draft UNIQUE (user_id, biz_type, request_id)
|
|||
|
|
);
|
|||
|
|
|
|||
|
|
CREATE INDEX IF NOT EXISTS ix_scan_draft_lookup ON scan_draft(user_id, biz_type);
|
|||
|
|
|
|||
|
|
COMMIT;
|