Time to make this thing interactive. I have a moderately strong opinion on something and need to know the performance ramifications.

The topic is SQL. Sub-topic: inner joins. Very, VERY often, I will see SQL such as:

FROM     Employee e,
         EmployeeDepartment ed,
         Department d,
         EmployeePosition ep,
         Position p
WHERE    e.EmployeeID = ed.EmployeeID
AND      ed.DepartmentID = d.DepartmentID
AND      e.EmployeeID = ep.EmployeeID
AND      ep.PositionID = p.PositionID
AND      e.EmployeeName = "Bobbie Sue Sister-Wife"

This is, of course, valid SQL. And I hate it. Here is how I would write it:

SELECT     *
FROM       Employee e
INNER JOIN EmployeeDepartment ed
ON         e.EmployeeID = ed.EmployeeID
INNER JOIN Department d
ON         ed.DepartmentID = d.DepartmentID
INNER JOIN EmployeePosition ep
ON         e.EmployeeID = ep.EmployeeID
INNER JOIN Position p
ON         ep.PositionID = p.PositionID
WHERE      e.EmployeeName = "Bobbie Sue Sister-Wife"

Both will return the same results but I like the second much better. The reason is thus: the filter is blatantly obvious. In most cases, I know the inner joins will be for stupid little tables that were included for the sake of normalcy and I can ignore them. I don't want to sift through all that crap in my where clause just to find out what data I really want. This way, I can quickly see where my data is coming from (i.e. the inner joins) and how it is filtered (i.e. the where clause). It's not all munged together for the sake of saving a few keystrokes.

This is especially true for complicated procedures and ones that involve outer joins. I never remember what direction += goes and it's not an easy thing to search for. Enter += into Google (or better yet, Google Groups) and see for yourself.

Here's where the interactive part comes in. Which one performs better? Note that in most cases, I'll go with the second one anyway because I don't think the performance is that much different as to make a noticeable difference either way. And I do prefer maintainable code over more-performant-than-anyone-will-notice code. But if I'm ever doing work on Amazon's database, I'd like to justify my astronomical rate.

So don't be shy. I'll be judging answers based on clarity of thought, support for my position, and potential clients.