Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 4: JOINs
Every time I teach a SQL class, I get asked the same question about CROSS JOINs: “Why in the world
would you use something like this?” I’m told there are scientific uses for it — this makes sense to me
since I know there are a number of high-level mathematical functions that make use of Cartesian products.
I presume that you could read a large number of samples into table structures, and then perform
your CROSS JOIN to create a Cartesian product of your sample. There is, however, a much more frequently
occurring use for CROSS JOINs — the creation of test data.
When you are building up a database, that database is quite often part of a larger-scale system that will
need substantial testing. A recurring problem in testing of large-scale systems is the creation of large
amounts of test data. By using a CROSS JOIN, you can do smaller amounts of data entry to create your
test data in two or more tables, and then perform a CROSS JOIN against the tables to produce a much
larger set of test data. You have a great example in the previous query — if you needed to match a group
of addresses up with a group of vendors, then that simple query yields 15 records from 8. Of course, the
numbers can become far more dramatic. For example, if we created a table with 50 first names and then
created a table with 250 last names, we could CROSS JOIN them together to create a table with 12,500
unique name combinations. By investing in keying in 300 names, we suddenly get a set of test data with
12,500 names.
Exploring Alter native Syntax for Joins
104
What we’re going to look at in this section is what many people still consider to be the “normal” way of
coding joins. Until SQL Server 6.5, the alternative syntax we’ll look at here was the only join syntax in
SQL Server, and what is today called the “standard” way of coding joins wasn’t even an option.
Until now, we have been using the ANSI/ISO syntax for all of our SQL statements. I highly recommend
that you use the ANSI method since it has much better portability between systems and is also much
more readable. It is worth noting that the old syntax is actually reasonably well supported across platforms
at the current time.
The primary reason I am covering the old syntax at all is that there is absolutely no doubt that, sooner
or later, you will run into it in legacy code. I don’t want you staring at that code saying, “What the heck
is this?”
That being said, I want to reiterate my strong recommendation that you use the ANSI syntax wherever
possible. Again, it is substantially more readable and Microsoft has indicated that they may not continue
to support the old syntax indefinitely. I find it very hard to believe, given the amount of legacy
code out there, that Microsoft will dump the old syntax any time soon, but you never know.
Perhaps the biggest reason is that the ANSI syntax is actually more functional. Under old syntax, it
was actually possible to create ambiguous query logic — where there was more than one way to interpret
the query. The new syntax eliminates this problem.
Remember when I compared a JOIN to a WHERE clause earlier in this chapter? Well, there was a reason.
The old syntax expresses all of the JOINs within the WHERE clause.
The old syntax supports all of the JOINs that we’ve done using ANSI with the exception of a FULL
JOIN. If you need to perform a FULL JOIN, I’m afraid you’ll have to stick with the ANSI version.