mysql创建if函数_PostgreSQL中的IF函数和MySQL一样

本文探讨了SQL标准与MySQL中IF函数的行为差异,特别是在处理除零错误时的安全性。建议在MySQL中启用严格模式,并推荐使用CASE表达式替代IF,以避免潜在的数据丢失。此外,提出了两种不推荐的解决方法,包括自定义除法运算符和使用PL/PgSQL异常处理,强调了重构应用程序和使用查询构建器以提高安全性的重要性。
摘要由CSDN通过智能技术生成

PostgreSQL遵循标准

这种行为似乎是specified by the SQL standard.这是我第一次看到这是一个真正的问题的案例;你通常只使用CASE表达式或PL / PgSQL BEGIN … EXCEPTION块来处理它.

MySQL的默认行为是危险和错误的.它只能以这种方式支持依赖于此行为的旧代码.当strict mode处于活动状态时(它绝对应该是),它已经是fixed in newer versions,但遗憾的是还没有成为默认值.使用MySQL时,始终启用STRICT_TRANS_TABLES或STRICT_ALL_TABLES.

ANSI标准的零分割有时会很痛苦,但它也可以防止导致数据丢失的错误.

SQL注入警告,考虑重新设计

考虑重新设计以向用户公开表达式构建器,并使用查询构建器从用户表达式创建SQL.这将更复杂,但更安全.

如果您不能这样做,请查看是否可以解析用户输入的表达式为抽象语法,在执行前验证它,然后根据解析的表达式生成新的SQL表达式.这样你至少可以限制他们可以写的东西,所以他们不会把任何恶意搞砸到表达中.您还可以重写表达式以添加检查零分割等内容.为代数表达式查找(或编写)解析器可能不是很难,但它取决于您需要让用户编写什么类型的表达式.

至少,应用程序需要使用一个角色(“用户”),该角色对表只有SELECT权限,不是超级用户,并且不拥有这些表.这将最小化任何SQL注入将导致的伤害.

CASE不会像写的那样解决这个问题

在任何情况下,由于您当前未验证且无法检查用户的表达式,因此无法使用SQL标准CASE语句来解决此问题.对于if(a / b> 0,a,b),您通常会写如下:

CASE

WHEN b = 0 THEN b

ELSE CASE

WHEN a/b=0 THEN a

ELSE b

END

END

这显式处理了零分母

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值