Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
cat_jesus
Aged Yak Warrior
547 Posts |
Posted - 2007-10-01 : 15:05:22
|
I really hate implicit joins. Really, I hate them almost as much as I hate cursors. I currently have the power to establish a no implict joins policy in my shop.Unfortunately(or fortunately) I am reluctant to do so without having solid reasons for doing so. My own personal dislike for them is simply a readability issue and I see that as personal.I've done some simple comparisons and found identical query plans either way. So other than the fact that I find implicit joins to be difficult to read is there any other reason to officially discourage their use? |
|
Kristen
Test
22859 Posts |
Posted - 2007-10-01 : 15:18:01
|
So, "implicit" is:SELECT *FROM Table1, Table2WHERE T1PK = T2PK and Explicit isSELECT *FROM Table1 JOIN Table2 ON T1PK = T2PK So what are you going to do for (implicit) OUTER and CROSS joins then?"simply a readability issue and I see that as personal"Nope, its a consistency issue. The Coders should adopt a consistent style (being more important that a Style-A v. Style-B debate). And that basically comes down to having a discussion about the various styles that folk like, and choosing one that you are going to adopt (and changing it, at HUGE cost, if you find later that it is flawed)What about select stuff from TableA with OPTIONALLY any rows from TableB [Outer Join], if any exist, but ONLY rows from TableB that ALSO have rows from TableC [Nested Inner Join]?By the by, I think the Readability thing is a BIG issue. The faster and more accurately that code can be read the less chance of mistakes during code-maintenance. If you are writing one-time-quickie-apps that may not be too important, but here we are single-product-long-lifespan, and maintenance considerations are 99% of the influence on such decisions.Kristen |
 |
|
Lamprey
Master Smack Fu Yak Hacker
4614 Posts |
Posted - 2007-10-01 : 16:39:30
|
I'll give you two solid reasons to do "explicit" joins: it's the right way to do it and it is the ANSI standard join syntax. :)It's also possible that the other way might be depercated in future version if SQL Server..? |
 |
|
cat_jesus
Aged Yak Warrior
547 Posts |
Posted - 2007-10-01 : 16:59:56
|
Thanks guys. Those are solid reasons. Any other reasons are certainly welcome but these are good enough and I'm going to make it official. Cursors have been banned too. You need to have a special need to use a cursor here. I've only found one place where a cursor was more efficient than using a set proccessing methodology and even then I don't think it would have qualified as a special need. |
 |
|
Kristen
Test
22859 Posts |
Posted - 2007-10-01 : 17:11:25
|
What you do is to post the Sequential Logic Cursor <Spit!> code here, and then Peso posts you some totally incomprehensible set-based solution by reply, and then you show your colleagues, and then they all go Wow!Job done!Kristen |
 |
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-10-01 : 17:26:11
|
quote: Originally posted by Kristen What you do is to post the Sequential Logic Cursor <Spit!> code here, and then Peso posts you some totally incomprehensible set-based solution by reply, and then you show your colleagues, and then they all go Wow!Job done!Kristen
Only if you're willing to wait 5 minutes while Peso re-writes your requirements to make them more understandable and then develops the code and test data.CODO ERGO SUM |
 |
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2007-10-01 : 17:43:22
|
quote: Originally posted by cat_jesusUnfortunately(or fortunately) I am reluctant to do so without having solid reasons for doing so. My own personal dislike for them is simply a readability issue and I see that as personal.
Do your employees have lots of Dilbert cartoons posted on the walls ?Damian"A foolish consistency is the hobgoblin of little minds." - Emerson |
 |
|
|
|
|
|
|