flask sqlalchemy审批流设计 sql 审核

转载

mob64ca140f9cec 2024-05-23 16:22:52

这是学习笔记的第 1771篇文章

SQL审核这个概念在近些年来被提得蛮火，算是和SQL优化在同一个量级的业务需求。

我们先来说下SQL审核的意义，要回答这个问题，就需要先解答下为什么要引入SQL审核，大多数情况下，人工审核SQL的代价太高；而且在规范落地和jian监督约束方面难以把控；大多数情况下，性能隐患会给线上环境带来极大的影响，可能是影响业务使用，也可能直接关系数据；规范落地没有一种数字化可视化的支持方式，落实规范基本靠拍脑袋想。

所以行业里也存在一些审核工具，比如Inception,SQL Advisor等，当然我们在此不着重介绍这些审核工具的细节，而是基于业务的场景来考虑。

对于SQL审核来说，我认为要它的核心是：

1）对业务同学来说，SQL审核是对标一种自助服务

2）我们不刻意做语法审核，专注于SQL规范的审核

而审核的难点更多是基于公司规范定制审核规则，有很多工具，方案，如果把基于自己特定业务的规范揉入进来，这是一个值得深思的问题。

理解了我所强调的核心，边界问题就相对清晰了，所以SQL审核这件事情，其实说简单也可以很简单，要说复杂，体系也可以很庞大。

一般来说，审核会覆盖几个维度：DDL, DML,DQL

他们的明细信息如下：

DDL：
     Create
     Alter:
        alter table ** add 
        alter table ** change
        alter table ** drop
        alter table ** modify
     Drop，
     Truncate
DML：
     Insert:
        insert into ** values(xxx)，(xxx);
        insert into ** select
        insert into ** set
     Update
     Delete
DQL：
     select **
     select ** inner join
     select ** union all

这样一些类别的SQL语句，我认为在初期或者要落地SQL规范，那么方向一定是先从DDL入手，也就是通泛的create语句和alter语句。

而对于查询语句而言，他们在规范方面可参考的信息很有限，所以更多会是在性能和安全方面做考量，所以基于查询，可以后续去补充通用查询模块，而DML的审核，在大多数情况下，应用是完全有权限修改数据的，在这个层面支持审核的意义我觉得更多是基于DML的闪回（即先得有备份）。所以从这些场景入手，可以基本明确，我们的大多数需求还是创建类的。

整个SQL审核的设计，本质是基于规范来完成，而作为一个工具或者产品，它一定有一些深耕的特性或者可以拿得出手的地方。大体来说，会有如下的四个亮点，也是在迭代开放的过程中初步沉淀下来的。

flask sqlalchemy审批流设计 sql 审核_迭代