Remember to print out the following definitions and keep them by your desk in case you forget what a complex right inner join is (from the article "Database design for platform independence", TechRepublic 2002):
Don't use joins
Joins become a problem with Oracle and SQL Server DBMSs because the two systems have fundamentally different approaches to the concept. Basically, joins don’t always work the same on every DBMS, and you can end up with unexpected result sets. Before we talk about the differences and how to get around them, you should understand the basic types of join clauses:The important thing to remember about joins is to not use them if you want your application to work well with different database servers.
- Join
Joins are powerful SQL commands for creating tables from data that is retrieved from multiple sources.- Equi-Join
Equi-Joins are formed by retrieving all the data from two separate sources and combining it into one, large table.- Inner/Outer Join
Inner Joins are joined on the inner columns of two tables. Outer Joins are joined on the outer columns of two tables.- Left/Right Join
Left Joins are joined on the left columns of two tables. Right Joins are joined on the right columns of two tables.- Compound/Complex Joins
There are also other kinds of joins—left/inner, left/outer, right/inner, and right/outer.
I love the way that it's exactly the kind of thing you would make up, if you were 12 and had absolutely no idea how to answer a homework question.
While I'm at it I can't help quoting a bit more, this time about the well-known ADD command:
ANSI SQL: CREATE, DROP, ADD, UPDATE, DELETE, INSERT, SELECT
As a rule, the only commands you should use are:
- CREATE and DROP for Data Definition Language (DDL).
- ADD, UPDATE, DELETE and INSERT for Data Manipulation Language (DML).
- SELECT for data retrieval.
6 comments:
I just want to know how on earth we can join the central columns of a table. There's no such thing, apparently, as a complex two-to-the-left-of-centre join. No wonder the author remained anonymous. There's not that many "experts" prepared to put their names to tripe...
Exactly - what if the table has an odd number of columns?
It says "Guest Contributor" at the top, but further down it credits a Sanders Kaufman, who could keep us in WTFs for years. Check out "Reasons to move your .NET network from Oracle to SQL Server" (the links at the bottom of the page are fun too).
From the Kaufman article mentioned:
"Local and external applications
To migrate applications, follow these steps:
1. Plug in a new SQL Server.
2. Create “devices” and build tables for use by the applications.
3. Take the application offline by disallowing applications’ access to it.
4. Copy the current data from Oracle to SQL Server.
5. Point all the applications at the new database.
6. Allow applications access to the new data tables and devices.
"
Cripes! Someone stop this guy before he causes a national disaster...
Those steps remind me of the old Monty Python sketch about the children's TV show where they explain how to cure all known diseases, and it went something like "Study very very hard and become a very famous, brilliant doctor. Then invent some medicine that will make everyone better, and make sure all the sick people can have some so they can all get well. Next week, we'll be showing you how to make box girder bridges..."
it is important to remember that the notion that a professional would stoop to simply fabricating information as a means of self-promotion is patently absurd and would certainly never happen - especially not in Oracle circles.
It simply couldn't happen in the Oracle community. There's too much professional integrity to suggest that anyone would make stuff up that wasn't tested, validated or correct... Nope. Never.
The Kaufman article has been immortalized by Cris Date in a scathing footnote to "SQL and Relational Theory" (I have the second edition).
Date doesn't mention Kaufman's name, but quotes the article sufficiently that it can be located via an internet search.
Post a Comment