4

我认为必须有一个特定的设计原因导致您不能编写如下查询：

select 
    (select column_name 
    from information_schema 
    where column_name not like '%rate%' 
    and table_name = 'Fixed_Income')
from Fixed_Income

而是不得不求助于动态SQL。

有谁知道这是什么原因？我试着用谷歌搜索它，但所有的点击都是寻求帮助解决问题的呼声——这意味着它是一个非常普遍的需求，而且还没有被很好地理解。

4

2 回答 2

6

原因是查询优化器需要知道您在编译时引用的确切模式对象。它需要他们来优化查询。如果没有这些信息可供查询优化器使用，您不会相信 RDBMS 会多么慢。

这有点像静态类型与动态类型在实践中的性能差异：通常存在不小的差异（我在这里只考虑主流语言）。编译器可以利用静态信息生成出色的代码。

即使存在此功能，也可以通过首先计算表名和列名，然后执行标准的“静态”查询计划来实现。

于 2012-06-06T19:59:40.487 回答
1

你问了一个非常有趣的问题。

“关系代数”中的“关系”是指名称-值对，而不是表之间的关系。在关系代数中，不要求集合（表）中的所有记录都具有相同的列。

我最好的猜测是，限制与实体关系图的想法有关。数据库是围绕表设计的，这些表之间存在关系。数据存储和访问的关系数据库的选择特别是当数据可以以这种方式存储时。了解实体及其属性表明了数据的静态形式，因此可以在查询中使用静态引用。

此外，SQL 作为一种语言是一种声明性语言，而不是一种过程性语言。这暗示了——但不强加——一个与查询运行分开的编译步骤。通常，SQL 引擎执行以下操作（在非常高的级别）：

  1. 将查询编译成某种数据流过程。
  2. 优化数据流流程。（通常是编译过程的一部分。）
  3. 运行查询。

前两个导致所谓的“查询计划”。但是，除非您了解正在操作的对象，否则您确实无法进行优化。因此，动态选择表和列意味着优化将成为运行查询的一部分，而不是编译它。

最后，一些数据库如 SQL Server 支持动态 SQL。这允许您构建同时编译和运行的字符串。这对于复杂的决策支持查询非常有用。当您需要快速的事务吞吐量时不建议使用，因为编译的开销相对于查询而言太高了。

于 2012-06-06T20:10:57.527 回答