Is there any difference between "!=" and "<>" in Oracle Sql? - sql

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

Related

sql negation operators : != vs <> [duplicate]

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.

Syntax for comparison expression in Simple case expression in Oracle DB SQL

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.

What is the difference between expression <> and != in Hibernate?

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.

Single Equals in MYSQL

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."

Openbase SQL case-sensitivity oddities ('=' vs. LIKE) - porting to MySQL

We are porting an app which formerly used Openbase 7 to now use MySQL 5.0.
OB 7 did have quite badly defined (i.e. undocumented) behavior regarding case-sensitivity. We only found this out now when trying the same queries with MySQL.
It appears that OB 7 treats lookups using "=" differently from those using "LIKE": If you have two values "a" and "A", and make a query with WHERE f="a", then it finds only the "a" field, not the "A" field. However, if you use LIKE instead of "=", then it finds both.
Our tests with MySQL showed that if we're using a non-binary collation (e.g. latin1), then both "=" and "LIKE" compare case-insensitively. However, to simulate OB's behavior, we need to get only "=" to be case-sensitive.
We're now trying to figure out how to deal with this in MySQL without having to add a lot of LOWER() function calls to all our queries (there are a lot!).
We have full control over the MySQL DB, meaning we can choose its collation mode as we like (our table names and unique indexes are not affected by the case sensitivity issues, fortunately).
Any suggestions how to simulate the OpenBase behaviour on MySQL with the least amount of code changes?
(I realize that a few smart regex replacements in our source code to add the LOWER calls might do the trick, but we'd rather find a different way)
Another idea .. does MySQL offer something like User Defined Functions? You could then write a UDF-version of like that is case insesitive (ci_like or so) and change all like's to ci_like. Probably easier to do than regexing a call to lower in ..
These two articles talk about case sensitivity in mysql:
Case Sensitive mysql
mySql docs "Case Sensitivity"
Both were early hits in this Google search:
case sensitive mysql
I know that this is not the answer you are looking for .. but given that you want to keep this behaviour, shouldn't you explicitly code it (rather than changing some magic 'config' somewhere)?
It's probably quite some work, but at least you'd know which areas of your code are affected.
A quick look at the MySQL docs seems to indicate that this is exactly how MySQL does it:
This means that if you search with col_name LIKE 'a%', you get all column values that start with A or a.