SELECT
C.CustomerID, C.CustomerName,
C.CustomerType, C.Address1,
C.City, C.State, SUM(S.Sales) as TotalSales
FROM
Customers C
INNER JOIN Sales S
ON C.CustomerID = S.CustomerID
GROUP BY
C.CustomerID, C.CustomerName,
C.CustomerType, C.Address1, C.City, C.State
Friday, April 11, 2008
Re: To Index or Not to Index
Whoa! This really heated up people. It seems there are a lot of people out with comments about this. But the recommendation by Ali Asghar is right on with our in-house experiment.
Microsoft recommends an index on a BIT column, especially in SQL 2K5. Our tables where we have opted for BIT columns, the data distribution ratio is 97:3. We created a non-clustered index and studying the execution plan, we can see a performance gain of 20% VS table scan. Ergo, index that column!
Thank you Ali and Adeel for your detailed insight :-)
If anyone wants the script for the test environment, feel free to contact us.
Microsoft recommends an index on a BIT column, especially in SQL 2K5. Our tables where we have opted for BIT columns, the data distribution ratio is 97:3. We created a non-clustered index and studying the execution plan, we can see a performance gain of 20% VS table scan. Ergo, index that column!
Thank you Ali and Adeel for your detailed insight :-)
If anyone wants the script for the test environment, feel free to contact us.
Thursday, April 10, 2008
To Index or Not to Index
Our DBA team has been discussing a lot recently about whether to index a BIT column in our tables or not.
Tell us what do you think. Do you think that a table scan would work just as fast as a non-clustered index seek?
Come on people, show us your DBA skills :-)
Tell us what do you think. Do you think that a table scan would work just as fast as a non-clustered index seek?
Come on people, show us your DBA skills :-)
Subscribe to:
Posts (Atom)