今日、相関クエリと非相関クエリとして知られる SQL サーバーの機能に出会いました。私の理解によると、上記の概念によって行われるタスクは、結合を使用して達成できます。
したがって、私の理解では、SQL サーバーのアーキテクチャには、この概念を思いつく前に、あらかじめ定義された目的がある可能性があります。知りたいです。
今日、相関クエリと非相関クエリとして知られる SQL サーバーの機能に出会いました。私の理解によると、上記の概念によって行われるタスクは、結合を使用して達成できます。
したがって、私の理解では、SQL サーバーのアーキテクチャには、この概念を思いつく前に、あらかじめ定義された目的がある可能性があります。知りたいです。
多くの場合、相関サブクエリはクエリとして書き直すことができます。また、SQL Server がこれらのアイデア (SQL、相関サブクエリ、または非相関サブクエリ) を発明したわけではないことも理解する必要があります。これらは、1970 年代後半に IBM によって指定された元の SQL 言語に戻ると確信しています。それらは間違いなく、1992 年の最初の SQL 標準に含まれていました。
相関サブクエリが必要な、または相関サブクエリが望ましい 3 つのケースを考えることができます。
まず、2 つのテーブル間で行を一致させようとするときに update または delete を使用する場合。この場合、構文は、そうでなければ結合となるものに対して相関サブクエリを必要とするようです。実際、SQL Server にはこれを回避するための構文が用意されていますが、最終的にはさらに複雑なアイデアが導入されます。たとえば、結合で 1 つのテーブルを更新するとはどういう意味でしょうか。
2 つ目は、相関サブクエリが row_number() などの特定のウィンドウ関数を使用する場合です。この場合、展開できない場合があります。
3 番目のケースは、効率の 1 つです。次のクエリを検討してください。
select *
from a
where a.blah in (select blah from b where b.foo = a.foo) and a.id in (list)
これは次のように展開できます。
select a.*
from a join
(select distinct b.foo, b.blah
from b
) b
on a.foo = b.foo and
a.blah = b.blah
where a.id in (list)
最初のケースでは、foo にインデックスがあり、b に blah がある場合、オプティマイザーはおそらくインデックスを使用し、集計は行いません。2 番目のケースでは、(私が知っている) ほとんどすべてのオプティマイザーが、1 行しか使用できない場合でも、サブクエリで集計を行います。