谈谈企业信息化 数据库应用中的SQL进攻型(积极型)编程

本文探讨了在企业进销存软件中采用SQL“进攻型”编程与“防御型”编程的不同之处,前者通过直接处理正常流程来简化代码并提高性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

何为数据库SQL“进攻型”编程或"积极型"编程?通常指先处理大概率发生事件,然后再处理小概率异常事件。我们以企业进销存软件销售模块中常见的销售订单审核为例,谈谈SQL“进攻型”编程和“防御型”编程的差异。

1、销售订单审核,程序要做的事情

以传统的饮料企业为例,销售订单审核,程序会做如下几个事情:
1)订单状态变更:录入状态 --> 已审核状态;
2)扣减客户资金(可用资金或折扣、报损等台账资金);
3)…

订单在“录入”状态还可以:
1)客户自己关闭订单,录入状态 变成 已关闭状态;
2)企业销售内勤关闭订单,比如所报产品没货,短期有无生产安排;
3)他人审核;

所以,订单审核时,必须核实订单状态是否为“录入”状态,只有录入状态,才可以审核。

2、SQL处理方式

1)进攻型编程处理方式

update sale_order set status = '已审核' where id = 1 and status = '录入';
if (@affectedRows != 1) {
	报错:"审核失败,订单状态发生变化,请刷新页面重试"
}
...

2)防御性编程处理方式

先获取订单:
select * from sale_order where id = 1;
判断订单状态 是否为 录入状态:
if (order.status != "录入") {
	报错:"审核失败,订单状态发生变化,请刷新页面重试"
}
更新订单状态:
update sale_order set status = '已审核' where id = 1;
...
3、小结

从上可以看出,SQL“进攻型”编程 相对 “防御性”编程来说:
1)代码少、简洁,开发效率高;
2)可以少执行一次查询SQL,性能更好;
对于企业信息化来说,实际操作中有很多类似订单审核这样一录、一审的操作,还有多人同时审核的操作,建议尽量使用SQL“进攻型”编程,代码简洁,便于维护。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值