How much is too much?

[Earl]

I'm working on a project with a database normalized to 4NF. I'd like to use
strongly typed datasets as much as possible on the main form, but it appears
I may need as many as 20-25 data adapters. What's the best practice here and
does that sound out of line?

 

[zackary.evans]

How many tables are we talking about here? Also how much data (row
count) will be placed in the strongly typed datasets?

There will certainly be a performance issue if there are several
hundred thousand rows being held by the client datasets and things
could get out of line quickly.

Consider flattening out your datasets a bit and only fetching data you
are sure the client will use.

Hope that helps a little bit, its tough to give a better answer without
more details.

 

[Marina Levit [MVP]]

I would forget typed datasets and all that design time stuff. That is just a
lot of overhead, and you lose a lot of control over what is truly going on.
Modifying these typed datasets is a pain, and it really amounts to a lot of
point and click programming.

Write the code yourself, fetch the data you need as you need it, so you are
not holding too much in memory. Or, if you are worried about round trips,
then you can control the amount of data you get a time to find the balance
between retrieving too much data all at once or having to go to the database
too often.

 

[Earl]

That is good thinking, alas, I did that for the last 3 years ... a lot of
work doing untype data dapters by hand, so I thought I might learn to do
something new. Using untyped datasets, I would often use the same adapter
over and over. The typed versions obviously demand their own data adapters.

Even with the typed datasets, you can control the amount of data you are
pulling. For example, each customer might have multiple quotes and pulling a
dataset by quote will only populate maybe a dozen records. The amount of
data in the dataset is not really the issue here, I'm more concerned about
using that number of objects.

Ironically, using typed datasets in this project has given me a different
perspective of the database design. Not an incorrect or non-normalized
design, but one where I can make some improvements at the margins.

 

[Earl]

Non-issue on the amount of data or on the "fetch", I was simply concerned
about the number of objects required on one form to implement my scheme.

 

[Marina Levit [MVP]]

I meant more in terms of the designer writing all this code for you, and
making it hard to keep track of what is really going on and when.

 

[Earl]

Heh ... yes, a boatload of designer code!

I meant more in terms of the designer writing all this code for you, and
making it hard to keep track of what is really going on and when.