Two-table-connected SQL statement: Which is the best way to do this? Which one is advocated now?
For example: a two-table-connected SQL has two ways of writing:
(1) Select A.c1,a.c2,b.c1,b.c2
From table1 a,table2 B
where a.id=b.id
(2) Select A.c1,a.c2,b.c1,b.c2
From table1 A join Table2 B
On A.id=b.id
Which kind of writing is good? Which one is advocated now?
Which one do you like to use?
I'm used to it (1)
Which one is better---these two?
The 11 floor answers the most in-depth. In fact, this problem still has a certain historical reasons, no matter what you are accustomed to writing as long as you know the ins and outs will not be confused by the details. The following views are for personal understanding, if there is deviation welcome correction.
Simply put, the former is the ANSI SQL 86 standard, the latter is the ANSI SQL 92 standard (* * *), the idea is most easily accepted.
What is ANSI? The National Bureau of Standards, one of the important members of ISO, was 1918.
What is ANSI SQL? It was ANSI that noticed the productivity of SQL and normalized it.
What is SQL? He was invented by IBM, Oracle to carry forward a broad language.
Why are there two companies?
In the early 70, because of the internal interests of IBM fierce struggle, leading to a study of Daniel's results can only be published in paper mode.
A small company in the late 70 used the technology in the business world as Oracle, until n years after IBM DB2 came out.
Therefore, SQL is not an ANSI invention, the ANSI standard does not have all the database platform.
For example, what is the syntax of the database below? The ANSI standard is an error in his case anyway.
SELECT * FROM (a INNER join B on a.id=b.id) inner join C on a.id=c.id
So what are the databases before ansi86? Oracle and DB2 are sure of it. In addition, there are some small roles at the time: Informix,dbase series.
The Sybase database and SQL Server came out 86 years later, and the strange join syntax in front of access was a.
Old SQL Server and Oracle I have not used, anyway, in 02 with Oracle8i did not support the ANSI 92 inner join, he was born in 97. The oacle9i that had been released until this century had changed. With more T-SQL people will ask left join do, where a.id=b.id (+) on it, others are not so stupid, T-SQL before there are *= such a representation.
So it looks like the ANSI standard is not enough? In fact, international standardization can not be across, in the ansi92 defined 4 levels, n many clauses. The idea is that everyone is in line with the entry level, other high-level is for informational purposes only, even ISO does not verify other levels at all. And things like inner join and left join are transition-level, embarrassing.
So I played 5 stars in front of that sentence is not completely correct, the right should be
The former conforms to ANSI 86 standard and ANSI 92 entry level standard, the latter conforms to ANSI92 transition level standard.
It is not that oracle8i does not conform to the ansi92, but that it does not conform to the ANSI92 high-level specification, and that the database system that fully implements the high level standard is not.
As early as the ORACLE7 has been fully compliant with ANSI92, of course, refers to the entry level, and he is the ansi92 template paradigm.
Return to the topic above, which of these two is good?
The performance is exactly the same, the difference is only habits and preferences, but also because of the different standard levels and have different risks.
If you want code that is elegant and easy to maintain and is not easy to write wrong, of course, use a high standard of the second method.
If it is necessary to consider the risk factor, such as migration or integration involving multiple platforms, you should use the first one, at least in the case of two tables, he is still relatively safe.
----
By the way, the ANSI standard has been revised: the number of specific versions are not enumerated, the benefits we get are many, such as recursion, objects, arrays, XML and so on in the mainstream of the new version of the database are implemented in succession