T-SQLで等しくない場合は！=または<>を使用する必要がありますか？

801

私が見てきたSQL用途の両方のこと!=と<>のために一致しません。推奨される構文は何ですか？なぜですか？

思い出す!=ので、私は好き<>ですVisual Basic。

sql  sql-server  tsql 
— ボブザ管理人
ソース
5
— ダイナ
コードの移植性。要件がANSI SQLで簡単に満たされる場合は、それを使用することをお勧めします。すべてのDBで同じコードを使用できます。例えば。サンプルコードを使用して基本的なSQLを説明したいSQLの本の著者。
— Steam
1
ANSI SQLコードのみが問題になる例を追加したいと思います。標準SQLでは、NULLの並べ替え方法を制御するオプションNULLS FIRSTおよびNULLS LASTがサポートされていますが、T-SQLはこのオプションをサポートしていません。
— Steam
再開する必要はありません。マークされた質問は重複していますが、もう1つのオプションで拡張されていますNOT (A = B)。
— TLama 2013年
@Steamでは、参照しているANSI SQLの年のバージョンを正確に指定する必要があります。これらのバージョンの一部では、レベルの互換性または標準の正確な部分を指定する必要があります。NULLS FIRSTとNULLS LASTを導入したのはどれですか？
— ガーマン、2015

回答:

539

技術的には、SQL Server AKA T-SQLを使用している場合も同じように機能します。ストアドプロシージャで使用している場合は、どちらを使用してもパフォーマンス上の理由はありません。それは個人の好みに帰着します。ANSI準拠であるため、<>を使用することをお勧めします。

さまざまなANSI標準へのリンクは、次の場所にあります。

http://en.wikipedia.org/wiki/SQL

— DBAndrew
ソース
41
私が使用!=したすべてのCの影響を受けた言語にその存在があり、Pythonのドキュメントに次のように記載されているため、私は常に使用することを好んでいました：「フォーム<>と!=同等です。Cとの一貫性のために、!=優先!=されます<>。<>スペルは旧式と考えられています。」しかし、SQLはPythonではありません。
— Iain Samuel McLean Elder
24
<>を使用するのは、XMLを思い出させるためです。しかし、SQLはXMLではありません！
— Rob Grant
32
はい; マイクロソフト自身もANSI準拠のために特別に使用<>することを推奨してい!=ます。たとえば、70-461試験用のMicrosoft Pressトレーニングキット「Querying Microsoft SQL Server」では、「標準フォームを選択するタイミングの例として、T-SQLは2つの等しい」演算子：<>と！=。前者は標準であり、後者はそうではありません。このケースは非常に簡単です：標準的なものにしてください！ "
— Matt Gibson
10
<>は、入力しやすいので好きです。
— user2023861
731

ほとんどのデータベースは!=（人気のあるプログラミング言語）をサポートし、<>（ANSI）を。

!=との両方をサポートするデータベース<>：

ANSI標準演算子のみをサポートするデータベース：

  • IBM DB2 UDB 9.5： <>
  • Microsoft Access 2010： <>
— Bill Karwin
ソース
Django ORMクエリはNOT (a = b)、(a <> b)またはの代わりにマップされます(a != b)。内部的に同じですか？
— ユーザー
7
@buffer、それらは論理的に同じです。つまり、同じ行のセットに一致または除外されます。ただし、特定のRDBMSブランドが同じように最適化するかどうかは、実装によって異なります。とは言っても、データベースのブランド間で何か違いがあるとしたら、私は驚くでしょう。
— ビルカーウィン2014
補足：C＃のLINQを使用する必要があります！=
— Tom Stickel
！=は、IBM DB2 LUW 10.5以降でサポートされています
— Cristi S.
10
C＃の@TomStickel LINQはSQLではありません。
— クレイグ
109

'<>'であるSQL-92標準と'!='され、独自の T-SQL演算子。他のデータベースでも利用できますが、標準ではないため、ケースバイケースで使用する必要があります。

ほとんどの場合、接続しているデータベースがわかるので、これは実際には問題になりません。最悪の場合、SQLで検索と置換を行う必要がある場合があります。

— アダム・ラセク
ソース
私もmysql sqlがそれを使用するのを見ました
— Bob The Janitor
3
標準言語へのこのような広範囲にわたる拡張機能を、独自の拡張機能と呼んでもよいでしょうか？この時点で、標準を更新して、必須または少なくとも両方の構文を許可する必要があるようです。
— JohanBoulé17年
3
@JohanBouleよく、SQLには書かれた標準があり、私の知る限り!=ではその一部ではありません。すべての実用的な目的にとってそれは事実上の標準ですが、標準機能とそうでない機能を混同しないでください。
— Adam Lassek
24

SQL Serverに関しては、どちらも有効であり、同じです。

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/not-equal-to-transact-sql-exclamation

— 狂った
ソース
これはSQL Server固有です。確かに彼はSQL Serverについて尋ねましたが、ANSI仕様のリファレンスを見つけて、その種のことを知りたいと思っている私たちにとって移植性が保証されているかどうかを確認できますか？
— Joel Coehoorn 2009
6
@Joel Coehoorn、T-SQLコードを移植した場合 "<>"と "！="で心配する必要はほとんどありません。
— 和基。
1
移植は問題ではありません。開発者が環境間を行き来する必要がある場合です。整合性は良好です。
— マークランサム
20

Microsoft自身は、表の制約<>から!=明らかなように好むようです。個人的に!=は「等しくない」と明確に読んでいるので使用することを好みますが[field1 != field2]、入力してコントラストとして保存すると、次にクエリを実行したときにと表示され[field1 <> field2]ます。これは、それを行う正しい方法はであると私に言い<>ます。

— カイル
ソース
15

!=は、非ANSIであるにもかかわらず、可読言語としてのSQLの真の精神に基づいています。それは等しくない悲鳴を上げます。 <>奇妙なのは私（より小、より大）にあると言います。私はそれが以下ではないか、または大きいために意図されていることを知っていますが、それは等しくないですが、それは本当に単純なことを言う非常に複雑な方法です。

私はいくつかの長いSQLクエリを取り、それらをXMLファイルに愛情を込めて配置する必要がありました。

XMLがまったくダウンし<>ていないと言うだけで十分であり、私が!=不正をする前に、XML を変更して自分自身をチェックする必要がありました。

— ファットアルバート
ソース
6
なぜCDATAだけではないのですか？クエリにXMLが含まれているとどうなりますか？
— Janus Troelsen 2012
12

T-SQLでは好きなように使用できます。ドキュメントには、どちらも同じように機能することが記載されています。!=私の（C / C ++ / C＃ベースの）心に「等しくない」と書かれているので私は好みますが、データベースの達人は好むようです<>。

— スティーブ
ソース
10

!=Unixの遺産（Sybase SQL Serverの時代、Microsoft SQL Server 6.5より前の時代）により、C構文がSQL Serverにあることを理解しています。

— カール
ソース
7

1つの代替方法は、Microsoft Docsで 2つの引数がNULLIFと等しい場合にNULLを返す、<>またはNULLIF !=を返すNULLIF演算子を使用することです。句はのために修飾することができるWHEREだから私は信じているし、次のように：<>!=

NULLIF(arg1, arg2) IS NOT NULL

私がそれを見つけたように、いくつかのケースで日付を使用する<>と!=機能しません。したがって、上記の式を使用する必要があります。

— ジテンドラプロヒット
ソース
6
この関数が<>すべてのコーナーケースでインデックスの使用に関して同様に機能するかどうかはわかりません。その上、読みやすさは確かにはるかに悪い...
— Lukas Eder
回答で述べたように、これは2014年に戻って日付フィールドで機能しました。他の回答を制限した条項/条件は不明ですが、一部の賛成票を見ると、これも他の人を助けているようです。
— jitendrapurohit
1

私が使用して優先!=の代わりに、<>時々私が使用しているため、<s></s>SQLコマンドを記述するために、構文を。!=この場合、構文エラーを回避するには、を使用する方が便利です。

— アンドレア・アントナンジェリ
ソース
-6

どちらもT-SQLで受け入れられます。ただし、を使用<>すると、よりもはるかに高速に動作するようです!=。を使用して複雑なクエリ!=を実行したところ、実行に平均で約16秒かかりました。これらをに変更する<>と、クエリの実行に平均で約4秒かかります。それは大きな改善です！

— ハムレット・ハビエル
ソース
20
SQL Serverで2つの類似したクエリを順番に実行すると、メモリにデータがキャッシュされ、類似したクエリ用に最適化される可能性があります。逆の順序で行った場合は、逆の結果になる可能性があります。
— codemonkey 2014
2
これも間違っています。まったく同じように機能する2つの演算子がなく、1つは「ただの原因」で低速でした。同じクエリが異なる実行時間を生成する理由については、多くの要因があります。
— Elliot Chance
-11

これらは同じように機能しますが、!=正確に「等しくない」ことを<>意味しますが、格納されている値よりも大きいまたは小さいことを意味します。

>=またはを検討してください。<=これは、クエリへのインデックスを考慮に入れるときに意味があります...<>場合によっては（適切なインデックスを使用して）高速に実行が、他の場合（インデックスなし）はまったく同じように実行されます。

これは、データベースシステムが値!=とを読み取る方法にも依存します<>。データベースプロバイダーは、ショートカットを作成して同じように機能させるだけなので、どちらの方法でもメリットはありません。PostgreSQLとSQL Serverはこれをショートカットしません。上記のように読み取られます。

— ケビン・キンチェン
ソース
3
声明の裏付けとなる参考資料はありますか？どちらの演算子も、PostgreSQL、Oracle、およびMySQLではまったく同じように見えます。
— GhostGambler 2014年
8
これは完全に間違っています。これらの文字を頭に入れて組み合わせると、「格納されている値よりも大きいまたは小さい」ように見えるかもしれませんが、レクサーにとっては、トークンを表すもう1つの方法にすぎません。
— Elliot Chance
関連リソースが不足しています！
— mostafa8026 2018
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.