生产系统中的动态SQL

您的一些问题的答案可以在这里找到 The Curse and Blessings of Dynamic SQL

有时你必须使用动态SQL,因为它会表现得更好

这取决于你所说的动态sql是什么意思。在参数值直接替换到sql字符串中的情况下构建的查询是危险的,应该避免,除非在极少数情况下没有其他选择。

使用平台支持的适当参数化查询机制的动态SQL可以非常强大。

评估动态SQL的使用时有几个考虑因素:

• 性能可能差异很大,具体取决于目标数据库引擎
• 维护在两个方向上都有很大的差异(例如,动态SQL可以采用 静态SQL无法实现的模块化技术)
• 动态SQL容易受到SQL注入攻击,但静态SQL(大多)不会
• 有时,您的需求使静态SQL(几乎)不可能实现,但这种情况应该很少见

记住,SQL是代码,RDBMS是另一个API。它并不特别,或者至少不多;像处理任何其他代码和API一样处理它。特别是,不要直接针对API进行代码编写:模块化代码并编写一些辅助方法,使其更容易和可重用。

“动态SQL”的成本因DBMS而异。

• 在IBM DB2中,查询计划可以预编译为机器代码,动态SQL的成本很高。

• 在IBM Informix(IDS-Informix Dynamic Server)中,大多数查询实际上是“动态SQL”(存储过程中的查询除外),因为SQL是在运行时解释的,即使客户端符号使用静态SQL。

我相信——尽管DB2专家可能会反驳我——DB2的CLI(ODBC,又名CCC)和JCC(JDBC)系统将所有SQL都作为动态SQL来处理。

我不知道Oracle、Sybase、MS SQL Server做了什么——我怀疑它们更接近IDS采用的路线,而不是DB2采用的路线。对于MySQL和PostgreSQL,如果它们的行为不比DB2更像IDS,我会感到惊讶。

因此,使用IDS,使用动态SQL没有特别的开销;在服务器级别,您的SQL无论如何都是动态的。其他DBMS可能还有其他因素在起作用。

所有服务器的一个问题是“如何从通过网络发送的SQL中识别预编译的查询”。使用DB2,预编译器识别所使用的包,应用程序和服务器之间的通信协议识别该包。我的理解是,ODBC和JDBC等DB2客户端不使用预编译包,因此我认为它们一直在有效地执行动态SQL。

小心动态SQL的SQL注入!

我以前的商店永远不会允许对数据库(SQL Server)执行此类操作。 这是被禁止的做法,DB被锁定以防止这种情况发生。 所有工作都通过对象(SP等)进行。

依我之见,这始终是正确的做法。

在某些边缘情况下,动态SQL比其他方法更容易、更快。只要你尽量少用它们,并且它们是动态生成的、准备好的参数化SQL,我就看不出它们有什么大问题。

动态SQL在生产代码中也有一席之地。执行带有安全漏洞的任意代码则不会。

一般来说,如果没有充分的理由使用动态SQL,我会避免使用它。动态SQL在运行之前不会被检查,所以你显然有更大的测试负担。然而,在处理管理任务、静态代码生成、适应不断变化的系统而无需基于查询元数据进行过度维护、使用DRY避免冗余等时,有很多好时机可以使用它。

我认为我们的系统中有很多动态SQL,主要是因为我们有很多动态创建的SQL 对象 (主要是表、索引、视图)。其中很多是遗产;2k5中的分区表之类的东西在我们的一些用例中有所帮助。但正如前文所述,你需要为其提供充分的理由;procs中的即时SQL通常有更好的(静态)解决方案。