Re: Using a "match" table to store multiple columns for parent data
- From: Erland Sommarskog <esquel@xxxxxxxxxxxxx>
- Date: Tue, 4 Mar 2008 22:41:06 +0000 (UTC)
(wfsmith@xxxxxxxxx) writes:
Performance-wise, would it be better to go this route or simply return
multiple record sets? E.g.
Select Products.* From Products
Select * from ProductCategories PC JOIN Categories C ON PC.CategoryID
= C.CategoryID
...and then just handle the different recordsets using a DataSet or
whatever on the code side?
If I understand your scenario I don't think there is much difference
in performance, although SQL Server will have to do some more work
with my approach. But if you are to get multiple result sets, you
would have to bounce the data around in the client code, to get your
grids as desired. That sounds like a lot of coding to me.
Then again, if you want to support any number of categories, it may be
better to do the pivoting client-side.
--
Erland Sommarskog, SQL Server MVP, esquel@xxxxxxxxxxxxx
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
.
- References:
- Prev by Date: Re: DB size increase from SQL 2000 to 2005
- Next by Date: Re: Each GROUP BY expression must contain at least one column that is not an outer reference
- Previous by thread: Re: Using a "match" table to store multiple columns for parent data
- Next by thread: 512 error in delete statement
- Index(es):
Relevant Pages
|
