Czy powinienem używać! = Lub <> dla nierówności w T-SQL?


800

Widziałem, SQLże używa obu !=i <>dla nie równych . Jaka jest preferowana składnia i dlaczego?

Lubię !=, bo <>mi przypomina Visual Basic.



Przenośność kodu. Jeśli ANSI SQL łatwo spełnia twoje wymagania, lepiej go użyć. Możesz użyć tego samego kodu we wszystkich bazach danych. Na przykład. Autor książki SQL, który chce zilustrować podstawowy SQL przy użyciu przykładowego kodu.
Steam,

1
Chciałbym dodać przykład, w którym posiadanie tylko kodu ANSI SQL może stanowić problem - Standard SQL obsługuje opcje NULLS FIRST i NULLS LAST, aby kontrolować sposób sortowania NULL, ale T-SQL nie obsługuje tej opcji.
Steam,

Nie ma potrzeby ponownego otwierania. Zaznaczony pytanie jest duplikatem, po prostu przedłużony o jeszcze jeden opcji NOT (A = B).
TLama,

@ Zespół, powinieneś określić, do której wersji ansi sql dokładnie się odwołujesz. Niektóre z tych wersji wymagają nawet określenia poziomu zgodności lub dokładnych części standardu. Który z nich wprowadził NULLS FIRST, a NULLS LAST?
Gherman

Odpowiedzi:


539

Technicznie działają one tak samo, jeśli używasz SQL Server AKA T-SQL. Jeśli używasz go w procedurach przechowywanych, nie ma powodu do wydajności, aby używać jednego nad drugim. Sprowadza się to do osobistych preferencji. Wolę używać <>, ponieważ jest zgodny z ANSI.

Linki do różnych standardów ANSI można znaleźć w ...

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


41
Zawsze wolałem używać !=ze względu na jego istnienie w każdym używanym przeze mnie języku, a dokumentacja Pythona mówi: „Formy <>i !=są równoważne; !=preferowana jest spójność z C ; tam, gdzie !=wspomniano poniżej, <>jest również akceptowane. <>pisownia jest uważane za przestarzałe.” Ale SQL to nie Python!
Iain Samuel McLean Starszy

24
Lubię używać <>, ponieważ przypomina mi XML. Ale SQL to nie XML!
Rob Grant,

32
Tak; Same firmy Microsoft zalecają stosowanie wyłącznie <>w !=celu zachowania zgodności z ANSI, np. W zestawie szkoleniowym Microsoft Press do egzaminu 70-461 „Zapytanie o Microsoft SQL Server”, mówią „Jako przykład kiedy wybrać standardowy formularz, T-SQL obsługuje dwa„ nie równa się operatorom: <> i! =. Pierwszy jest standardowy, a drugi nie. W tym przypadku powinien być nobrainer: wybierz standardowy!
Matt Gibson,

10
Lubię <>, ponieważ łatwiej jest pisać.
user2023861

731

Większość baz danych obsługuje !=(popularne języki programowania) i <>(ANSI).

Bazy danych, które obsługują zarówno !=a <>:

  • MySQL 5.1: !=i<>
  • PostgreSQL 8.3: !=i<>
  • SQLite: !=i<>
  • Oracle 10g: !=i<>
  • Microsoft SQL Server 2000/2005/2008/2012/2016: !=oraz<>
  • IBM Informix Dynamic Server 10: !=i<>
  • InterBase / Firebird: !=i<>
  • Apache Derby 10.6: !=i<>
  • Sybase Adaptive Server Enterprise 11.0: !=i<>

Bazy danych obsługujące standardowego operatora ANSI, wyłącznie :

  • IBM DB2 UDB 9.5: <>
  • Microsoft Access 2010: <>

Zapytanie Django ORM mapuje na NOT (a = b)zamiast (a <> b)lub (a != b). Czy to samo wewnętrznie?
użytkownik

7
@bufor, są logicznie takie same, tzn. pasowałyby lub wykluczały ten sam zestaw wierszy. Ale to, czy konkretna marka RDBMS ją optymalizuje, zależy od implementacji. Powiedziałbym, że byłbym zaskoczony, gdyby istniały jakiekolwiek różnice między markami baz danych.
Bill Karwin

uwaga dodatkowa: LINQ w C # musisz użyć! =
Tom Stickel

! = jest obsługiwany przez IBM DB2 LUW 10.5+
Cristi S.,

10
@ TomStickel LINQ w C # nie jest SQL.
Craig

109

'<>' jest z SQL-92 i '!='jest zastrzeżonym operatorem T-SQL. Jest on dostępny również w innych bazach danych, ale ponieważ nie jest to standard, musisz brać go indywidualnie.

W większości przypadków będziesz wiedział, z którą bazą danych się łączysz, więc to nie jest tak naprawdę problem. W najgorszym wypadku może być konieczne wyszukiwanie i zamiana kodu SQL.


Widzę, że mysql sql również z niego korzysta
Bob The Janitor

3
Czy możemy nadal nazywać tak rozpowszechnione rozszerzenie standardowego języka zastrzeżonym ? W tym momencie wydaje się, że standard powinien zostać zaktualizowany, aby wymagać lub przynajmniej zezwolić na obie składnie.
Johan Boulé

3
@JohanBoule cóż, istnieje pisemny standard SQL i według mojej wiedzy !=nie jest jego częścią. Chociaż dla wszystkich praktycznych celów jest to standard defacto, nie powinniśmy mylić, jakie są i nie są standardowymi funkcjami.
Adam Lassek



24

To jest specyficzne dla SQL Server. To prawda, że ​​pyta o SQL Server, ale czy możesz znaleźć odniesienie do specyfikacji ANSI, aby sprawdzić, czy jest to przenośne dla tych z nas, którzy lubią wiedzieć tego rodzaju rzeczy?
Joel Coehoorn

6
@Joel Coehoorn, jeśli bardzo przeniesiesz swój kod T-SQL „<>” i „! =” Będzie najmniejszym zmartwieniem !!
KM.

1
Przenoszenie nie jest problemem - wtedy, gdy jako programista musisz poruszać się między środowiskami. Spójność jest dobra.
Mark Ransom,

20

Wydaje się, że Microsoft sami wolą <>się !=czym świadczy w swoich ograniczeń tabeli. Osobiście wolę używać, !=ponieważ wyraźnie czytam to jako „nie równe”, ale jeśli wprowadzisz [field1 != field2]i zapiszesz jako constrait, przy następnym zapytaniu pojawi się jako [field1 <> field2]. To mówi mi, że poprawny sposób to zrobić <>.


15

!=, mimo że nie jest ANSI, jest bardziej w prawdziwym duchu SQL jako czytelnego języka. Wrzaski nie są równe. <>mówi, że to dla mnie (mniej niż, więcej niż), co jest po prostu dziwne. Wiem, że intencją jest, aby była mniejsza lub większa niż odtąd nie równa, ale to naprawdę skomplikowany sposób powiedzenia czegoś naprawdę prostego.

Właśnie musiałem wziąć kilka długich zapytań SQL i umieścić je z miłością w pliku XML z wielu głupich powodów, dla których nie będę wchodził.

Wystarczy powiedzieć, że XML wcale nie działa <>i musiałem je zmienić !=i sprawdzić się, zanim sfałszowałem się.


6
dlaczego nie po prostu CDATA? co się stanie, gdy zapytanie zawiera XML?
Janus Troelsen,

12

W T-SQL możesz używać dowolnych opcji. Dokumentacja mówi, że oba działają w ten sam sposób. Wolę !=, ponieważ czyta „nie równe” mojemu umysłowi (opartemu na C / C ++ / C #), ale guru bazy danych wydają się preferować <>.


10

Rozumiem, że składnia C !=jest w SQL Server ze względu na jej dziedzictwo uniksowe (w czasach Sybase SQL Server, wcześniejszych niż Microsoft SQL Server 6.5).


7

Jedną alternatywą byłoby użycie operatora NULLIF innego niż <>lub !=zwracającego NULL, jeśli dwa argumenty są równe NULLIF w Dokumentach Microsoft . Więc wierzę WHERE mogą być modyfikowane dla <>i !=, co następuje:

NULLIF(arg1, arg2) IS NOT NULL

Jak się przekonałem, w niektórych przypadkach używanie <>i !=nie działa w przypadku daty. Dlatego użycie powyższego wyrażenia robi to, co potrzebne.


6
Nie jestem pewien, czy ta funkcja działałaby tak dobrze, jak <>w odniesieniu do użycia indeksu we wszystkich przypadkach narożnych. Poza tym czytelność jest zdecydowanie gorsza ...
Lukas Eder

Jak wspomniałem w odpowiedzi, działało to dla mnie w polach dat w 2014 roku. Nie jestem pewien, jaka klauzula / warunek ogranicza inne odpowiedzi, ale patrząc na niektóre opinie, wydaje się, że pomaga to również innym.
jitendrapurohit

1

Wolałem używać !=zamiast, <>ponieważ czasami używam <s></s>składni do pisania poleceń SQL. Użycie !=jest bardziej przydatne, aby uniknąć błędów składniowych w tym przypadku.


-6

Oba są akceptowane w T-SQL. Wydaje się jednak, że korzystanie <>działa znacznie szybciej niż!= . Właśnie uruchomiłem złożone zapytanie, którego !=uruchomienie zajęło mi średnio około 16 sekund. Zmieniłem je na, <>a uruchomienie zapytania zajmuje teraz średnio około 4 sekund. To ogromna poprawa!


20
Jeśli uruchomisz dwa podobne zapytania jeden po drugim w SQL Server, prawdopodobnie będą one buforowane dane w pamięci i zoptymalizowane pod kątem podobnych zapytań. Jeśli zrobiłeś to w odwrotnej kolejności, możesz znaleźć odwrotny wynik!
klucz kodowy

2
Jest to również błędne, nie mieliby dwóch operatorów, którzy działaliby dokładnie tak samo, a jeden działałby wolniej „tylko dlatego”. Istnieje wiele czynników, które przyczyniają się do tego, że to samo zapytanie spowoduje różne czasy wykonania.
Elliot Chance

-11

Chociaż działają w ten sam sposób, !=oznaczają dokładnie „nie równy”, a <>oznaczają większą i mniejszą niż przechowywana wartość.

Zastanów się >=lub <=, a to będzie miało sens, gdy uwzględnisz swoje indeksy w zapytaniach ...<> w niektórych przypadkach będzie działać szybciej (z odpowiednim indeksem), ale w niektórych innych przypadkach (bez indeksu) będą działać tak samo.

Zależy to również od tego, jak system baz danych odczytuje wartości !=i <>. Dostawca bazy danych może po prostu skrócić go i sprawić, by działały tak samo, więc nie ma żadnej korzyści w żaden sposób.PostgreSQL i SQL Server nie skracają tego; jest czytany tak, jak pokazano powyżej.


3
Czy masz jakieś odniesienia do swojego oświadczenia? Oba operatory wydają się być dokładnie takie same w PostgreSQL , Oracle i MySQL .
GhostGambler

8
Jest to całkowicie niepoprawne, może ci się wydawać, że „większe niż i mniejsze niż przechowywana wartość”, kiedy połączysz te postacie w swoim umyśle, ale dla leksykonu jest to tylko inny sposób przedstawienia tokena.
Elliot Chance

Brak powiązanych zasobów!
mostafa8026
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.