代码之家 › 专栏 › 技术社区 › cmsjr

生产系统中的动态SQL

sql

cmsjr · 技术社区 · 16 年前

因此,对于如何使用动态SQL完成各种任务有很多问题,通常响应中会附带警告和免责声明,说明实际使用所提供方法的合理性。我的工作环境从“知道如何使用光标是一个坏符号”到“sp_executesql是否整洁!”.

当涉及到生产系统时,应该始终避免使用动态SQL,或者应该在编程工具箱中有一个有效的位置。如果不是这样,为什么?

8 回复 | 直到 16 年前

SQLMenace 16 年前

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

有时必须使用动态SQL,因为它的性能更好

Joel Coehoorn 16 年前

这取决于您所说的动态SQL的含义。在直接替换到SQL字符串中的参数值处生成的查询是危险的,应该避免这种情况,除非很少出现没有其他选项的情况。

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

Rob Williams 16 年前

在评估动态SQL的使用时,有几个注意事项:

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

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

Jonathan Leffler 16 年前

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

在IBMDB2中,可以将查询计划预编译为机器代码,动态SQL的成本非常高。
在IBMInformix(IDS-Informix动态服务器)中,大多数查询实际上是“动态SQL”(存储过程中的查询除外),因为SQL是在运行时解释的,即使客户端表示法使用静态SQL。

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

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

因此,对于ID,使用动态SQL没有特别的开销;在服务器级别,您的SQL仍然是动态的。其他DBMS可能有其他因素在起作用。

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

注意使用动态SQL的SQL注入!

pearcewg 16 年前

我以前的商店决不允许对数据库(SQL Server)执行此类操作。作为惯例,这是被禁止的,并且数据库被锁定以防止这种情况发生。所有工作都通过对象(SP等)。

这是一个正确的方法,总是这样,imho。

Jonas Elfström 16 年前

有些边缘情况下,动态SQL比其他方案更容易、更快。只要您将它们保持在很小的范围内,并且它们是动态生成的、准备好的参数化SQL,我就不会发现它们有什么大问题。

Cade Roux 16 年前

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

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

Joe 16 年前

我们的系统中有很多我认为是动态SQL的东西,主要是因为我们有很多动态创建的物体 (主要是表、索引和视图)。其中很大一部分是遗留的;像2K5中的分区表之类的东西在我们的一些用例中有些帮助。但是正如前面提到的,您需要为它做一个很好的案例;在运行中,procs内部的SQL通常有一个更好的(静态)解决方案。