ChatGPT解决这个技术问题 Extra ChatGPT

Should I use != or <> for not equal in T-SQL?

I have seen SQL that uses both != and <> for not equal. What is the preferred syntax and why?

I like !=, because <> reminds me of Visual Basic.

Portability of code. If your requirements are easily met by ANSI SQL, then its better to use it. You can use the same code in all DB's. Eg. An SQL book author who wants to illustrate basic SQL using sample code.
I'd like to add an example where having only ANSI SQL code can be a problem - Standard SQL supports the options NULLS FIRST and NULLS LAST to control how NULLs sort, but T-SQL doesn’t support this option.
There no need for reopening. The marked question is a duplicate, just extended by yet one more option, NOT (A = B).
Because it reminds you of Visual Basic is kind of a bad reason. This question can certainly do without that opinion in it. A better reason would be like the reason in one of the answers where SQL is being stored in XML. Not sure why one would want to store SQL in XML, but it's a better reason nonetheless.

9
9 revs, 5 users 71%

Most databases support != (popular programming languages) and <> (ANSI).

Databases that support both != and <>:

MySQL 5.1: != and <>

PostgreSQL 8.3: != and <>

SQLite: != and <>

Oracle 10g: != and <>

Microsoft SQL Server 2000/2005/2008/2012/2016: != and <>

IBM Informix Dynamic Server 10: != and <>

InterBase/Firebird: != and <>

Apache Derby 10.6: != and <>

Sybase Adaptive Server Enterprise 11.0: != and <>

Mimer SQL 11.0: != and <>

Databases that support the ANSI standard operator, exclusively:

IBM DB2 UDB 9.5: <>

Microsoft Access 2010: <>


Django ORM query maps to NOT (a = b) instead of (a <> b) or (a != b). Is it the same internally?
@buffer, they are logically the same, that is, it would match or exclude the same set of rows. But whether a particular RDBMS brand optimizes it the same is implementation-dependent. That said, I would be surprised if there were any differences across brands of database.
side note: LINQ in C# you have to use !=
!= is supported by IBM DB2 LUW 10.5+
@TomStickel LINQ in C# is not SQL.
P
Peter Mortensen

Technically they function the same if you’re using SQL Server AKA T-SQL. If you're using it in stored procedures there is no performance reason to use one over the other. It then comes down to personal preference. I prefer to use <> as it is ANSI compliant.

You can find links to the various ANSI standards at...

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


I had always preferred to use != because of its existence in every C-influenced language I have used, and because the Python documentation says: "The forms <> and != are equivalent; for consistency with C, != is preferred; where != is mentioned below <> is also accepted. The <> spelling is considered obsolescent." But SQL is not Python!
I like to use <> because it reminds me of XML. But SQL is not XML!
Yes; Microsoft themselves recommend using <> over != specifically for ANSI compliance, e.g. in Microsoft Press training kit for 70-461 exam, "Querying Microsoft SQL Server", they say "As an example of when to choose the standard form, T-SQL supports two “not equal to” operators: <> and !=. The former is standard and the latter is not. This case should be a nobrainer: go for the standard one!"
I like <> because it's easier to type.
I always prefered != over <> because != is consistent with every single programming language I know, I know programmers who first started using SQL and whenever they see a <> they go what is that??
P
Peter Mortensen

'<>' is from the SQL-92 standard and '!=' is a proprietary T-SQL operator. It's available in other databases as well, but since it isn't standard you have to take it on a case-by-case basis.

In most cases, you'll know what database you're connecting to so this isn't really an issue. At worst you might have to do a search and replace in your SQL.


I have see mysql sql use it as well
Can we keep calling such a widespread extension to the standard language a proprietary one ? At this point, it just seems the standard should be updated to require, or at least allow both syntaxes.
@JohanBoule well, there is a written standard for SQL and to my knowledge != is not a part of it. Even though for all practical purposes it is a defacto standard, we shouldn't confuse what are and are not standard features.
It says not not SQL-92 standard that's more than 25 years old, so I highly doubt SQL-92 is even used today...... @JohanBoulé
P
Peter Mortensen

The ANSI SQL Standard defines <> as the "not equal to" operator,

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt (5.2 <token> and <separator>)

There is no != operator according to the ANSI/SQL 92 standard.


You do know that the 92 standard is more than 25 years old right..... If you are writing SQL using 25 year old standard, I am a bit worried about your code honestly.....
@Yunfei Chen The point is not that people are likely to be writing in a system that only supports things included in the ANSI/SQL 92 standard. The point is that things included in the ANSI/SQL 92 standard have broader consistent coverage in database systems than things that are not included in the standard. That's enough reason to prefer "<>". If someone created a new DBMS that your existing database code might be ported to one day, and it only supported one of the two operators - it's far more likely to be "<>" than "!=".
If you're porting DB code between DBMS's changing != to <> is going to be the least of your problems...
J
Jibin Balachandran

<> is the valid SQL according to the SQL-92 standard.

http://msdn.microsoft.com/en-us/library/aa276846(SQL.80).aspx


Both are valid, but '<>' is the SQL-92 standard.
J
Jibin Balachandran

It seems that Microsoft themselves prefer <> to != as evidenced in their table constraints. I personally prefer using != because I clearly read that as "not equal", but if you enter [field1 != field2] and save it as a constrait, the next time you query it, it will show up as [field1 <> field2]. This says to me that the correct way to do it is <>.


K
Kolappan N

They're both valid and the same with respect to SQL Server,

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


That's SQL Server specific. Granted he asks about SQL Server, but can you find an ANSI spec reference to see if it's guaranteed to be portable for those of us who like to know that sort of thing?
@Joel Coehoorn, if you very port your T-SQL code "<>" and "!=" will be the least of your worries!!
Porting isn't the issue - it's when, as a developer, you're required to go back and forth between environments. Consistency is good.
J
Jibin Balachandran

!=, despite being non-ANSI, is more in the true spirit of SQL as a readable language. It screams not equal. <> says it's to me (less than, greater than) which is just weird. I know the intention is that it's either less than or greater than hence not equal, but that's a really complicated way of saying something really simple.

I've just had to take some long SQL queries and place them lovingly into an XML file for a whole bunch of stupid reasons I won't go into.

Suffice to say XML is not down with <> at all and I had to change them to != and check myself before I riggedy wrecked myself.


why not just CDATA it? what happens when your query contains XML?
what happens when someone needs a query with a less-than comparison? Or any other XML reserved symbol? This is the oddest reason I have ever heard for preferring one over the other. What about when you are writing C code, do you have a preference for operators that can be expressed in XML without escaping?
S
Steve

You can use whichever you like in T-SQL. The documentation says they both function the same way. I prefer !=, because it reads "not equal" to my (C/C++/C# based) mind, but database gurus seem to prefer <>.


K
Karl

I understand that the C syntax != is in SQL Server due to its Unix heritage (back in the Sybase SQL Server days, pre Microsoft SQL Server 6.5).


K
Kolappan N

One alternative would be to use the NULLIF operator other than <> or != which returns NULL if the two arguments are equal NULLIF in Microsoft Docs. So I believe WHERE clause can be modified for <> and != as follows:

NULLIF(arg1, arg2) IS NOT NULL

As I found that, using <> and != doesn't work for date in some cases. Hence using the above expression does the needful.


I'm not sure if this function would perform as well as <> with respect to index usage in all corner cases. Besides, the readability is certainly much worse...
As I mentioned in the answer, this worked for me on the date fields back there in 2014. Not sure what the clause/condition was which restricted other answers, but looking at some of the upvotes, this seems to be helping others too.
You were probably comparing dates that had a time component. using CAST(date1) AS DATE <> CAST(date2) AS DATE is a better way to go IMHO
A
Andrea Antonangeli

I preferred using != instead of <> because sometimes I use the <s></s> syntax to write SQL commands. Using != is more handy to avoid syntax errors in this case.


This is a good explanation for your preference of using one over the other.
J
Jkyle Landicho

Both works and I think any difference would be very negligible! Just focus on productivity guys!

What is the value of your script? What does it do? How will it contribute to the business? Will it make more money?

Focus on these goals instead of these programmer prefered preferences. This is like which is better C# or Visual Basic languages. As if the end user cares what was used to write the App?

What the end user cares about is what your App could do. How could it help him with what he is doing.


P
Peter Mortensen

They are both accepted in T-SQL. However, it seems that using <> works a lot faster than !=. I just ran a complex query that was using !=, and it took about 16 seconds on average to run. I changed those to <> and the query now takes about 4 seconds on average to run. That's a huge improvement!


If you run two similar queries one after the other in SQL Server, it will likely have cached data in memory and optimized for similar queries. If you did it in the reverse order, you might find the opposite result!
This is also wrong, they wouldn't have two operators that functioned exactly the same and one was slower "just 'cause". There are many contributing factors as to why the same query will produce different execution times.
Just look at the execution plans to see if they are different