U8存货编码如何实现唯一性校验？

Question

在U8系统中，如何确保存货编码在全局范围内唯一？常见问题表现为：新增存货时因编码重复导致保存失败，但系统未及时提示；或在批量导入存货档案时，由于缺乏前置校验机制，造成数据冲突。尤其在多用户并发操作或与外部系统集成场景下，仅依赖界面层校验难以保证唯一性。如何通过数据库约束、触发器或存储过程，在服务端强制实施存货编码的唯一性校验，成为保障数据一致性的关键技术难点。

Answer 1

一、U8系统中存货编码唯一性保障的背景与挑战

在用友U8 ERP系统中，存货档案是供应链管理的核心基础数据之一。存货编码作为其唯一标识符，必须在整个系统范围内保持全局唯一。然而，在实际业务场景中，由于多用户并发操作、批量导入、外部系统集成（如MES、WMS）等复杂交互，仅依赖前端界面校验难以杜绝重复编码问题。

常见现象包括：

• 新增存货时提示“保存失败”，但未明确指出是编码重复；
• 批量导入过程中因编码冲突导致部分记录插入失败，影响整体数据完整性；
• 多个子系统同步写入数据库时出现竞态条件（race condition），造成逻辑冲突；
• 界面层虽有JS校验，但可被绕过或异步请求延迟响应。

因此，必须从数据库服务端层面建立强制性约束机制，以确保无论通过何种途径写入数据，都能有效防止编码重复。

二、层级递进的技术实现方案

1. 第一层：应用层校验（客户端/中间件）
2. 第二层：数据库唯一索引约束（基础防线）
3. 第三层：触发器实时拦截非法插入
4. 第四层：存储过程封装安全写入逻辑
5. 第五层：分布式锁与事务控制（高并发场景）

2.1 应用层校验 —— 初级防护

大多数U8客户端会在表单提交前调用API查询当前编码是否已存在。例如使用SQL语句：

SELECT cInvCode FROM Inventory WHERE cInvCode = 'INV001'

若返回结果非空，则阻止保存。但此方式存在时间窗口漏洞：两个请求几乎同时发起查询，均未发现冲突，随后各自插入，导致唯一性破坏。

2.2 数据库唯一索引 —— 强制保障

最根本且高效的手段是在数据库表 Inventory 的 cInvCode 字段上创建唯一索引：

-- 创建唯一索引
CREATE UNIQUE INDEX IX_Inventory_cInvCode 
ON Inventory(cInvCode) 
WHERE cInvCode IS NOT NULL;

该索引能自动拒绝任何尝试插入重复值的操作，并抛出明确错误（如 SQL Server 错误 2601）。即使来自不同接口（API、Excel导入、第三方系统），只要触及数据库，即受约束保护。

2.3 触发器校验 —— 精细化控制

对于需要自定义提示信息或日志记录的场景，可使用触发器增强处理能力：

CREATE TRIGGER tr_CheckUniqueInvCode
ON Inventory
INSTEAD OF INSERT
AS
BEGIN
    IF EXISTS (
        SELECT 1 FROM Inventory i 
        INNER JOIN inserted ins ON i.cInvCode = ins.cInvCode
    )
    BEGIN
        RAISERROR('存货编码已存在：%s', 16, 1, (SELECT TOP 1 cInvCode FROM inserted));
        ROLLBACK TRANSACTION;
        RETURN;
    END
    ELSE
    BEGIN
        INSERT INTO Inventory SELECT * FROM inserted;
    END
END

注意：建议优先使用唯一索引，触发器应作为补充而非替代。

2.4 存储过程封装 —— 安全入口统一化

将所有存货新增操作路由至统一的存储过程，便于集中校验和事务管理：

参数名	类型	说明
@cInvCode	VARCHAR(50)	存货编码
@cInvName	VARCHAR(255)	存货名称
@cMemo	VARCHAR(500)	备注
@ResultCode	INT OUTPUT	返回状态码
@ResultMsg	VARCHAR(200) OUTPUT	返回消息

CREATE PROCEDURE sp_InsertInventory
    @cInvCode VARCHAR(50),
    @cInvName VARCHAR(255),
    @cMemo VARCHAR(500),
    @ResultCode INT OUTPUT,
    @ResultMsg VARCHAR(200) OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION;
        
        IF EXISTS (SELECT 1 FROM Inventory WHERE cInvCode = @cInvCode)
        BEGIN
            SET @ResultCode = -1;
            SET @ResultMsg = '存货编码已存在：' + @cInvCode;
        END
        ELSE
        BEGIN
            INSERT INTO Inventory (cInvCode, cInvName, cMemo)
            VALUES (@cInvCode, @cInvName, @cMemo);
            
            SET @ResultCode = 0;
            SET @ResultMsg = '插入成功';
        END
        
        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
        SET @ResultCode = ERROR_NUMBER();
        SET @ResultMsg = ERROR_MESSAGE();
    END CATCH
END

2.5 高并发与外部集成下的优化策略

在多线程批量导入或微服务架构对接U8时，需引入更高级机制：

• 使用WITH (UPDLOCK, SERIALIZABLE)提示锁定查询范围；
• 采用Redis或ZooKeeper实现跨节点分布式锁；
• 前置校验服务独立部署，供所有系统调用；
• 异步队列（如Kafka）削峰填谷，避免瞬时高并发写入。

三、实施建议与流程图

推荐按照以下流程构建完整的唯一性保障体系：

graph TD
            A[用户提交新增请求] --> B{是否通过API/界面?}
            B -- 是 --> C[调用校验接口检查编码]
            B -- 否 --> D[直接写入数据库]
            C --> E[是否存在?]
            E -- 存在 --> F[返回错误并终止]
            E -- 不存在 --> G[执行INSERT]
            D --> H[数据库唯一索引拦截]
            G --> H
            H -- 冲突 --> I[抛出唯一约束异常]
            H -- 成功 --> J[数据持久化]
            K[批量导入工具] --> L[调用存储过程逐条处理]
            L --> G

该模型结合了应用层预判与数据库强制约束，形成纵深防御体系。

四、监控与运维支持

为持续保障系统健壮性，建议配置如下监控措施：

监控项	检测频率	告警方式	处理建议
唯一索引冲突次数	每5分钟	邮件+短信	排查来源系统
触发器异常日志	实时	日志平台告警	审查触发逻辑
存储过程调用失败率	每小时	企业微信通知	性能调优
批量导入成功率	每日	报表展示	优化模板规则
并发写入延迟	实时采样	APM工具追踪	引入缓存或队列

通过日志分析工具（如ELK）收集SQL Server错误日志，定位高频冲突点，反向推动上游系统改进数据质量。