drew.allen - Wednesday, December 27, 2017 7:13 AM
I'll second that. In most cases, this happens because someone thought it would be a whole lot easier if they denormalized data or they don't know what normalization is. In some cases, it's simply because people don't understand the data and have left some important criteria out of the JOINs. It can also happen for the same reason when people write huge "all in one" queries where a little "Divide'n'Conquer" to capture the main controlling data early in a Temp Table will make a server crushing 45 minute run take only 3 seconds to execute because all of the "distinct" functionality is no longer necessary and millions (sometimes billions) of internal rows no longer need to be generated.
The other thing to watch for is people that use GROUP BY to solve the same issues that DISTINCT does (usually, incorrectly).
It's not possible for us to make a recommendation without knowing the nature of the data in the tables in the query but the "Divide'n'Conquer" method may be just what the doctor order even for a query with so few joins especially if some of the tables have a lot of data.
As a bit of a sidebar (and I know it's only example code), whenever there's more than one table involved in a query, ALWAYS use the 2 part naming convention (tablealias.columnname) for all columns in the SELECT List. It's makes troubleshooting a whole lot easier and will prevent a meltdown if someone happens to add an identically named column to one of the other tables.
--Jeff Moden
Change is inevitable... Change for the better is not.