Recently I's learning Hibernate by reading its official guide document, Today I get confused when studying the chapter 'Expressions', all examples in document use '<>' expression to check it 2 columns are equal instead of '!=', so I want to ask question what is the difference between '<>' and '!='? and what advantage does '<>' have?
Thanks so much.
No difference.
The SQL standard is actually <> for "not equals", but (virtually?) every database allows != as a synonymous operator, because most application languages use !=. Hibernate allows it too.
<> and = are opposites -- <> refers to Not Equal.
Related
This question already has answers here:
What is the difference between <> and != operators in MySQL? [duplicate]
(4 answers)
Closed 7 years ago.
Why are there two negation operators in SQL language? != and <>.
Are they redundant or is there a difference between them depending on operands ?
Which one should I use to negate strings in MySQL ?
<> is ISO Sql Standard
!= is vendor specific
They both have no difference among them. It is just a personal preference which one to use. I always prefer <> since it is a ISO SQL standard
The SQL standard only specifies <> for not equals. SQL:2011 Foundation, section 5.2 <token> and <separator> specifies:
<not equals operator> ::=
<>
However some SQL implementations (like MySQL) also support != as a lot of programmers are more familiar with != for not equals. They are fully equivalent, so you can use either, but from a standards point of view you should use <>.
See also the MySQL documentation for not equals.
I am trying to make a parser for Oracle SQL select statement which include CASE statement
http://docs.oracle.com/cd/B19306_01/server.102/b14200/img/case_expression.gif
And the oracle reference listed that the simple case expression can be expressed in
http://docs.oracle.com/cd/B19306_01/server.102/b14200/img/simple_case_expression.gif
But i cannot find the comparison expression everywhere in the reference, does anyone have a clue where is it and how it looks like?
I believe it's the same as the condition defined here:
http://docs.oracle.com/cd/E11882_01/server.112/e26088/conditions001.htm#SQLRF52101
which means it can be several kinds of things, requiring all of chapter 7 of the manual to explain them. And most of them in turn can include arbitrary expressions (that's all of chapter 6, plus chapter 5 for function calls) and even subqueries (so all of chapter 9 too). For eaxmple this is a "simple case statement" in action:
SELECT
CASE
WHEN (SELECT /* anything that can go in a select statement might be here */) > 0
THEN 'Y'
ELSE 'N'
END
FROM DUAL
And in the nested query you can have all kinds of hard-to-parse things. Basically if you want to parse a CASE expression the way Oracle would parse it, you're in trouble. There's no way to avoid the need to parse the rest of Oracle SQL.
If you limit yourself to standard SQL (and maybe ban subqueries) you have a better chance of finishing the project.
OK, first answer was exactly the opposite of the truth. comparison_expr is an expr that will be compared to the expr that comes right after the CASE.
I would like to know if there are any differences in between the two not equal operators <> and != in Oracle.
Are there cases where they can give different results or different performance?
No there is no difference at all in functionality.
(The same is true for all other DBMS - most of them support both styles):
Here is the current SQL reference: https://docs.oracle.com/database/121/SQLRF/conditions002.htm#CJAGAABC
The SQL standard only defines a single operator for "not equals" and that is <>
Actually, there are four forms of this operator:
<>
!=
^=
and even
¬= -- worked on some obscure platforms in the dark ages
which are the same, but treated differently when a verbatim match is required (stored outlines or cached queries).
At university we were taught 'best practice' was to use != when working for employers, though all the operators above have the same functionality.
According to this article, != performs faster
http://www.dba-oracle.com/t_not_equal_operator.htm
I was wondering why MYSQL uses a single equals sign in conditional statements instead of the more typical two equals signs. Is there a technical/historical reason for this? Thanks.
Hi, I was wondering why MYSQL uses a single equals sign in conditional statements instead of the more typical two equals signs. Is there a technical/historical reason for this? Thanks.
Comparison is much more common in SQL than assignment.
That's why SQL uses more short syntax to do more common things.
In classical SQL, comparison can be distinguished from assignment by context (assignment can be only in SET clause of an UPDATE statement), that's why one operator can be used for both operations.
In MySQL's extension to SQL, assignment to a session variable is denoted by :=
More like historical.
It's SQL. It has used a single equals sign for comparison since the early '70s.
There is never a case for ambiguity in SQL.
In the original A Guide to the SQL Standard by C.J.Date (1987 edition), = for assignment is only used in the SET clause of UPDATE. Everywhere else = is used it is used for comparison.
But in other languages, such as C/C++/C#/Java, = can be used as assignment but it also returns a value. So a = b means "set a equal to b, and return a" whereas a == b means "return true if a and b are equal". (This leads to a very common bug in C programs, because if (a = b) and if (a == b) are both valid, since the result doesn't have to be a bool.)
Some languages like JavaScript/ECMAScript also introduce === as a third type of comparison. In those languages, == means "convert to same type and compare" whereas === means "return true only if they are the same type and same value."
I'm looking at some SQL code which has a WHERE clause like this:
WHERE 'USD' = CCY
I asked the writer why he's putting the value on the left hand side, and he said it's best practice to do so, stemming from C++ where people could mistakenly assign the value instead of comparing equality by forgetting the second equals sign.
I've never seen this before.
What are your thoughts?
Er, C++ is not SQL. There's no == in SQL and no assignments in a WHERE clause.
I'm not sure it qualifies as "best practice" but there is a convention which places the known value on the right-hand side. So, with a literal as in your example that would be
WHERE CCY = 'USD'
Best practise in c++ does not make it best practise in SQL. The query optimizer will not care, so it is just a matter of preference, but I have to say it would not be my preference or how I would naturally write it.
Never seen it in SQL, where of course the C++ reasoning does not apply, as '=' is not an assignment operator in this context. also, a lot of C++ programmers (including me) don't like this style.
If you look at it:
'USD' = CCY
is essentially the same:
CCY = 'USD'
As for:
it's best practice to do so, stemming
from C++ where people could mistakenly
assign the value instead of comparing
equality by forgetting the second
equals sign.
Well, i have never seen this happen, and if this was that important, we would definitely have seen this somewhere and this would have been practiced by most if not by all.
I personally would not do it that way, but put the column name on the left hand side as this to me is more readable / easier to follow within an SQL query.
I've very rarely seen it done the opposite way, and don't think the reason given is really applicable to SQL (as has been pointed out, it's "=" in SQL, not "==")
If he says it's a best practice, I'd ask him to prove that with SQL not C++ sources. Since 99.9% of the SQL code I've ever read (including our code, other organization's code, Microsoft help files, SQL Blogs, etc) does the opposite of what your dev does, I'd say that violating the normal expectation of the developer who will maintain the code is a bad idea. In SQL we expect to see the form
WHERE CCY = 'USD'
not
WHERE 'USD' = CCY
Therefore the professsional would also write code in that manner to ensure it is clear to the maintainer.