11

私は 10 年以上 SQL (SQL Server、PostgreSQL) を使用していますが、まだ使用したことがなく、本番コードでキーワードを使用ANY/SOMEしていません。ALL私が遭遇したすべての状況は、、、、、で回避でき、INより読みやすいと思います。MAXMINEXISTS

例えば：

-- = ANY
select * from Users as U where U.ID = ANY(select P.User_ID from Payments as P);

-- IN
select * from Users as U where U.ID IN (select P.User_ID from Payments as P);

または

-- < ANY
select * from Users as U where U.Salary < ANY(select P.Amount from Payments as P);

-- EXISTS
select * from Users as U where EXISTS (select * from Payments as P where P.Amount > U.Salary);

ANY/SOMEと の使用ALL:

質問は次のとおりです。他のソリューションに勝る状況はありANY/SOMEますか?ALL

4

3 に答える 3

13

ANY と ALL は、平等または不平等をテストするだけではない場合に非常に便利です。検討

'blah' LIKE ANY (ARRAY['%lah', '%fah', '%dah']);

この質問に対する私の回答を使用しました。

ANY、ALLおよびそれらの否定は、そうでなければ自明でないサブクエリまたは CTE を必要とするコードを大幅に簡素化することができます。

ANYどの演算子でも機能することを考慮してください。LIKEとで非常に便利~ですが、tsquery、配列メンバーシップ テスト、hstore キー テストなどでも機能します。

'a => 1, e => 2'::hstore ? ANY (ARRAY['a', 'b', 'c', 'd'])

また：

'a => 1, b => 2'::hstore ? ALL (ARRAY['a', 'b'])

なしANYで、またはALLおそらくVALUES、集計を使用してリストに対するサブクエリまたは CTE としてそれらを表現して、単一の結果を生成する必要があります。もちろん、必要に応じてそれを行うこともできますが、私は に固執しANYます。

ここで注意すべき点が 1 つあります。古いバージョンの Pg で を書いているANY( SELECT ... )場合は、ほぼ確実に を使用した方がパフォーマンスが向上しEXISTS (SELECT 1 FROM ... WHERE ...)ます。オプティマイザーが結合に変わるバージョンを使用している場合はANY (...)、心配する必要はありません。疑わしい場合は、EXPLAIN出力を確認してください。

于 2013-07-11T09:03:35.737 に答える
0

私は何かを試しましたが、何も欠けていませんでしたNot.条件を使用した場合にのみ、異なるタイプの習慣がありました. exists と in は not を追加する必要がありますが、 any/some は演算子を に変更するだけ<>です。私はSQLサーバーのみを使用しており、他のソフトウェアに何かが欠けている可能性があるかどうかはわかりません

于 2013-07-11T08:27:11.880 に答える