views:

64

answers:

3

The CUST table below will be joined with ~10 tables.

For this subquery in particular, am I better off simply joining up directly with the Customer table and moving the subquery's 4-part WHERE clause to the main query's WHERE clause?

I'm primarily wondering if it is possible to cut down on the amount of processing that SQL Server has to do if we localize portions of the master WHERE Clause by creating subqueries as below.

select * From 
(select CKey, CID, CName from MainDB.dbo.Customer 
     where 
        LOC = 'ARK' 
        and Status = 1 
        and CID not like 'KAN%' 
        and CID not like 'MIS%') as CUST
+3  A: 

Based on what you provided, there's no need for the subquery. Without the ~10 joins to the derived table CUST, it's extremely difficult to say what should or should not be done.

OMG Ponies
+5  A: 

In older versions, yes, I've seen huge improvements using derived tables (not a subquery) rather then all in one JOIN/WHERE. It's less relevant now since SQL Server 2005

However, why not try both and see what happens?

gbn
@gbn In reference to your question, I would like to know the underlying theory as to why one way or the other is better. Anecdotal evidence won't give me much confidence and I'll end up doing the same tests every time I deploy such queries... and there's a lot. Thanks for the answer... if you have a reference laying around I'd be interested
hamlin11
A: 

I suggest that if you are joining that many tables it would be better to build a view.

DaveWilliamson
Why is building a view recommended? I have to built a lot of complex queries like this... I'd have a lot of views
hamlin11
A view is a macro that expands = the same query anyway...
gbn
@hamlin11 Building views is good for multi-table joins which are typically re-used over and over. This allows you to have a modular structure, which can makes things easier to maintain. Having views proliferate through the database for every query is NOT a good idea. Judicious use of views and inline table-valued functions can bring good organization to a database.
Cade Roux
@Cade Ok that makes sense. I have to vary these queries enough per instance that it doesn't make sense, but I already have 3 views that I use when general case usage is possible. I believe we're on the same page. Thanks
hamlin11
@hamlin11 TVFs and super-views which are general enough to be used in different ways at the next layer can be useful. In 3NF databases, though there is a limit due to many-to-one and many-many relationships - you can't just join everything willy-nilly. In star schemas (like data warehousing, the majority of my current workload), a general view layer is easy to build and can supersede almost all direct table queries.
Cade Roux
@hamlin11 Using a view abstracts the complexity of the joins so that you can focus on selecting. In the larger query it could afford you more clarity when deciding to use the extended WHERE or the subquery. In larger data scenarios you may find that Indexing the view could cut the read rates depending on more specifics than we know from the question posed.
DaveWilliamson