better to join at DB or at client?

  • Thread starter Thread starter SteveK
  • Start date Start date
S

SteveK

So I'm getting my head aroud the DataSet and the "disconnected" way of
working with data. One thing that I'm finding is that to work disconected,
I need more data in my query results than I used to.

For example, in my order table I have a FK userID column, since I want to be
able to search and refine my disconnected data, I need to retrieve the FK as
well as join the Tbl_Users record that correlates to the FK.

My question is, is it faster to retrieve all the data from the DB already
joined or would I be better off getting separate tables and creating my
relations on the client side? I will be poppulating a treeView and for
every record retrieved from my orders table (estimated 6000+ and growing) I
have several related records in other tables.


Anyone have any advice? Suggestions, benchmarks?

A little more info:
- SqlServer 2000 (upgrading soon)
- C# windows form clients
 
If you mean "which component should I add relationship logic to", I do not
believe it really matters if you are joining with ADO.NET (which I see no way
around). The DataSet is passed across boundaries as XML, so joining on the
server is as costly as the client, unless the client machines are horrible,
speed wise.

If that is not what you mean, please rephrase.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Joins at the server will cause you nothing but problems in your
insert/update/delete code. The only good use for joins on the server is when
you are populating read-only data such as in reports. Just accept that you
have to build the relationships at the dataset and it will make it easier to
"get your head around the dataset".
 
Back
Top