SQL Server Management Studio がサブクエリの構文検証をバイパスすることがあるのはなぜですか?

SQL Server Management Studio: 予期しないサブクエリの動作

SQL Server Management Studio (SSMS) は、無効なフィールドを参照するサブクエリを含むクエリを処理するときに、予期しない動作を示すことがあります。 SSMS は通常、構文検証を実行しますが、特定の状況下ではこれらのエラーを驚くほど見落とす可能性があり、開発者に混乱を引き起こす可能性があります。

次の例を考えてみましょう:

delete from Photo where hs_id in (select hs_id from HotelSupplier where id = 142)

このクエリは、Photo から選択するサブクエリで見つかった hs_id 値に基づいて、HotelSupplier テーブルからエントリを削除することを目的としています。 ただし、HotelSupplier には hs_id フィールドがありません。代わりに hs_key を使用します。

興味深いことに、このクエリは、単独で実行するとサブクエリ自体が失敗するにもかかわらず、SSMS ではエラーなしで実行されることがよくあります。

select hs_id from HotelSupplier where id = 142

説明

SSMS の動作は、修飾されていない列参照の処理に起因します。 hs_id 参照は、サブクエリではなく、外部クエリ (Photo) に属するものとして解釈されます。 これは、最も外側のスコープから内側に向​​かって修飾されていない列名を解決するルールに従います。

サブクエリは明示的に列を選択しないため、SSMS は事実上クエリを次のように書き換えます。

delete from Photo where Photo.hs_id in (select * from HotelSupplier where id = 142)

サブクエリが行を返す場合 (おそらくここでそうであるように)、Photo が NULL ではない hs_id 内のすべての行が削除されます。 サブクエリからの空でない結果セットにより、IN 句は非 NULL 値に対して true と評価されます。

重要なポイント

この一見直感に反する動作は、SQL クエリで完全修飾列名 (HotelSupplier.hs_key など) を使用することの重要性を強調しています。 これにより、あいまいさがなくなり、予測可能なクエリ実行が保証され、予期しないデータの削除やその他の意図しない結果が回避されます。

以上がSQL Server Management Studio がサブクエリの構文検証をバイパスすることがあるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。