Design issues when dealing with multiple DataSets

  • Thread starter Thread starter malcolm
  • Start date Start date
M

malcolm

Hello,

We have a robust (.NET 1.1 c# winforms) client-server application that
utilizes many typed DataSets, typed DataTables and typed DataRows. Our
application is a series of windows and popup windows where you can
edit information and data, nothing out of the ordinary. I estimate we
have something like 50 to 100 tables and/or views in our database each
of which map to one strongly typed DataTable. Now we have some odd 20
to 30 typed DataSets throughout our application, only some of which we
have managed to be able to re-use.

We're starting to run into design quirks by having all of these
DataSets. The .NET rule that an instance of a DataTable can only live
in one DataSet is the cause for most of these quirks, but to be frank,
I'm ok with this rule and I think the issues are more subtle, maybe
our design approach in general.

One idea that I keep having, only I can't convince myself of why it
would work, is to have 1 instance of a Typed DataSet in our entire
application. This typed DataSet probably should be a non-static
instance that is passed around from our startup form (although static
would be easier maybe...). From a design point of view, this would
solve a lot of our issues, but I think the efficiency would be bad...
or would it???

I mean, this dataset would have like 100 tables in it, ideally with
relationships defined also!!! Some tables could have 10,000 rows,
would this be crazy to store in one dataset? I'm thinking we could
simply add and remove data to keep the amount of memory required to
normal levels. Has anybody ever attempted this approach and if so, did
you like it? Or is this like the whole point of DataSets and what is
actaully recommended?

If this approach is not a good idea (which is what my instincts tell
me), then another big issue we have comes into play when we launch
popups that edit data. In particular, it's when these popups are
complex and have thier own DataSets then issues occur because each
consumer may have two additional (entirely different) DataSets.

-dave
 
Hi Malcolm,

I feel that having all datatables in the same dataset will be a better
option because of the following reasons:
* you have data relations between different tables
* having 100 tables in the same data set won't matter...unless a datatable
is instantiated, it won't consume memory.

But there is one issue though...the schema file for such a dataset will be
very hugh - maybe around 5 MB or so. This could be tough to handle,
especially if you are going to use VSS. It could take a significant amount of
time to get the latest version, check in etc.

HTH,
Rakesh Rajan
 
Hi Rakesh,

Thanks for your reply. This would not be much of an issue for us
because we actually create our typed datasets and typed datatables by
hand. In other words, we do not use schema.. our system is very
dynamic and rely heavily on typed datasets that derive from lower
level typed datasets... (this is why we don't use schemas).

The issues I worry about with this model is there may be instances
when I need the same tables that are related in slightly different
ways in different scenerios. By going with 1 typed dataset, you are
essentially locking yourself into that model.

Have you ever gone with this approach? I was wondering if there are
other ways to overcome these issues. The single dataset wasn't
exactly the entire point of this post, but more a single possible
solutions. I'm just curious for those who have developed large
applications that rely heavily on typed data objects, specifically how
they used these objects. For example, I have come across these tips
(learning them the hard way):

1) When making a popup that edits some data, make the popup take a
currecny manager if possible and bind to that currency manager. This
is desireable when you want to edit a single row in a table. If you
want to edit the whole table however, then passing the table is the
only (clean) way I can think of.
2) Try to never do the actuall saving of data in the popup. This is
because you may be in a popup yourself that may have a cancel button.
Not saving the data allows you to conditionally cancel any the popup
may have performed. This becomes an issue of re-use of the popups. By
doing this a lesser issue (i think it's lessor) arrises: code
duplication, but that's a much easier problem to solve...

Now here are the issues I'm dealing wiht specifically:

1) Issues start arrising when the popup you are editing contains
several other tables that you don't necessarily need in the parent
form. This is where the issues start to occur. If the parent form has
a dataset with several tables, then I cannot put the table that I want
ot edit in the popup in the popup's dataset and create relations off
of it. Here are the solutions that I know of each suck:
a) If either the parent or popup window don't have a dataset, then
we lose all sorts of functionality in one of the two places.
Relationships, HasChanges, etc... This has been kind of the model
we've been moving to (the popups are usually the one without there own
datasets. but this becomes complicated when the popup is complicated)
b) If the parent contains all of the tables that the popup needs
and passes it's own dataset, then you've killed two importing things.
Effeciency and re-use. To me this is the least desireable because you
are forcing the parent to have this type of dataset (not to mention it
must have more than one dataset) also and also forcing them to have
all these tables...
c) Is the single dataset the solution!!! See issues above, these
are only guesses though.

Or has anyone come up with other design patters? We don't have time to
implement the single dataset solution even if we knew it was the right
way to go.

Thanks,
dave
 
Back
Top