(从维护的角度来看)使用Jinja或String串联动态构造复杂的SQL查询更好吗？

Question

两种可能性。在可读性、维护和干净代码方面，哪种方法更好：

可以忽略SQL注入。

1. 使用python字符串连接构造复杂的参数化sql查询。最多有7个参数，每个参数添加一个附加where条件、逻辑顺序或将子查询包装到新的select中。特定请求的sql字符串构造由python函数处理，该函数调用向SQL字符串添加部分的其他函数。
2. 使用Jinja模板语言进行SQL查询构造。有一个base.sql模板将被扩展到具有主SQL查询和Jinja宏处理其他逻辑的特定请求。SQL驻留在.sql文件中。对于特定的请求，将调用python函数，该函数打开相应的.sql文件，传递参数，并构建最终的SQL查询。

Answer 1

您忘记了第三种解决方案:重写代码，这样您就不需要模板引擎来构建SQL查询了。

说真的，当查询变得如此复杂，以至于您需要问这个问题时，您就错了，而且您自己也在为自己的未来而头疼。症状包括：

• 当看你已经构建的代码时，会感到头晕目眩。
• 在代码评审期间，每分钟WTF的比率很高。
• 你的同事说的坏话，他们不得不维护这个东西，在代码、模板和数据库本身之间跳转。
• DBA的坏话，如果他们发现你做了什么。
• 如果查询一直在变化，那么性能就会降低(如果没有，为什么需要模板引擎？)
• SQL注入你现在抛弃了它，也许你是完全正确的，但它迟早会困扰你。“哦，谁能想到这段五年前的代码会这样用呢？”
• 困难测试。

上下文:在过去的一周里，我研究了一些遗留代码，其中有一个跨200+行的SQL查询，它是动态构建的。这不是一次有趣的经历。