Hi

Which is likely to be more efficient and/or best practice
1 Dataset with 10 table
o
10 Datasets with 1 tabl

(The tables are not related

Thank
Dav

It would be a smaller memory footprint with 1 dataset with 10 tables. As
far as what would be more efficient, it really depends. I think it would be
negligable either way.

Whats wrong with just having 10 independant tables if they are not related?

--
Eric Marvets
Principal Consultant

the bang project

<shameless self promotion>

Email (E-Mail Removed) for Information on Our Architecture and
Mentoring Services

</shameless self promotion>

For many reasons, 1 dataset with multiple tables is going to be the 'better'
approach.

1) It will be a lot harder to remember the names of all datasets
2) Storing the tables in one dataset mirrors your real world database (or
at least mirrors it more closely) in almost every situation out there, so
logically the placement makes more sense.
3) You can iteratively access each table in a dataset much easier than
accessing one table in 10 datasetz (this goes with #1).
foreach(DataTable dt in myDataSet.Tables{
//Do something
}
or, if you had an array of dataadapters that corresponded to the positions
in a dataset, youi could use a for loop and call update on each dataAdapter
using the interator as an index
for(int x = 0; x< myDataSet.Tables.Count; x++){
((SqlDataAdapter)AdapterArray[x]).Update(myDataSet.Tables[x]);

}

If you later decide tht the tables would benefit by relations or something
like that, it'll be logically easier to reference and use.

Since DataSet are colllections of datatables, then it follows that having a
collection of objects is more logically consistent than having collections
of one object.

Sure there are probably instances where this doesn't all hold or that one of
the reasons may not be applicable, but in the majority of cases, one dataset
is all you need. It will be easier for trading partner and other
programmers to undrestand a more mainstream design etc.

HTH,

Bill



www.devbuzz.com
www.knowdotnet.com
http://www.msmvps.com/williamryan/
"Dave Moyle" <(E-Mail Removed)> wrote in message
news:CFCBA246-B13B-4439-BF5F-(E-Mail Removed)...
> Hi,
>
> Which is likely to be more efficient and/or best practice:
> 1 Dataset with 10 tables
> or
> 10 Datasets with 1 table
>
> (The tables are not related)
>
> Thanks
> Dave
>

Hi Bill,

Do you mind if I have a small note by this.

In my opinion I would not choose for 10 in one when you want to serialize a
part of it, because by instance that you want to use it on the Interernet,
when you have to place it in a session or more of this kind of reasons..

Than I go for the smallest dataset which is possible, which does not
directly denies what you are writting however it can conflict with that,
therefore just a note.

Cor

Good point Cor.

I guess my main point was that in general, grouping tables in one dataset
follow the collections methodology throughout the framework and follows the
Local Database metaphor.

Like you mention, there are going to be instances where this doesn't fit. I
should probably have been more articulate about when it would make sense to
have multiple datasets.

In the web example, you use, let's say that you have a bunch of large tables
but only need one or two of them for most of the app and at the end you
needed to write the data to xml as you mention and transfer it to a PDA.
While you could store the whole dataset in session state, you'd invariably
put a whole lot of stuff in SS that you don't need which is a waste of
resources. You could opt to store only the two tables of the dataset that
you'll use all the time in session state, but then you'd need to extract
them from Session variables and add them to one (or in this case) two
separate datasets if you wanted to write them to XML. In this type of
scenario, it may well be easier to use multiple sets and it may also be much
more efficient. I can also think of a few others where it would be simpler
to implement using multiple datasets, no doubt about it.

But on the whole, particularly on desktop apps, you can do most of what
you'll need to do with one dataset. Actually, you can do just about anything
just using one dataset but like you point out, it may not be the most
efficient way or the easiest to code.

The 'exceptions to the rule' would probably be a really good article to
write about ;-).

As always, you have some really good insight and raise some really good
points.

Thanks again,

Bill

--
W.G. Ryan MVP Windows - Embedded

www.devbuzz.com
www.knowdotnet.com
http://www.msmvps.com/williamryan/
"Cor Ligthert" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Bill,
>
> Do you mind if I have a small note by this.
>
> In my opinion I would not choose for 10 in one when you want to serialize
a
> part of it, because by instance that you want to use it on the Interernet,
> when you have to place it in a session or more of this kind of reasons..
>
> Than I go for the smallest dataset which is possible, which does not
> directly denies what you are writting however it can conflict with that,
> therefore just a note.
>
> Cor
>
>

Thanks guys. Precisely what I needed to know.

The fact that you are bringing in 10 tables (either way you choose) means
something is architecturally wrong.

The fact that no one even brought that up is a clear indication that there
are no practicing DBA's who replied to your question.

10 tables in anything, one has to wonder if there was a better way in the
first place. I certainly hope it wasn't a JOIN. I can see a UNION....but no
way, a JOIN.......




"Dave Moyle" <(E-Mail Removed)> wrote in message
news:B5833E78-77A6-46EB-BAB4-(E-Mail Removed)...
> Thanks guys. Precisely what I needed to know.

int <(E-Mail Removed)> wrote:
> The fact that you are bringing in 10 tables (either way you choose) means
> something is architecturally wrong.
>
> The fact that no one even brought that up is a clear indication that there
> are no practicing DBA's who replied to your question.
>
> 10 tables in anything, one has to wonder if there was a better way in the
> first place. I certainly hope it wasn't a JOIN. I can see a UNION....but no
> way, a JOIN.......

You think 10 tables is too many to have in an application? It's
perfectly easy to have *way* more than that.

I would rather have lots of tables with few columns than a few tables
with masses and masses of columns.

Would you also like to limit applications to having fewer than 10
classes?

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Hi Int,

Do you really understand what is written, I did not see anywhere about
bringing in 10 tables.
In my opinion was the question using one dataset container for those tables.

> The fact that you are bringing in 10 tables (either way you choose) means
> something is architecturally wrong.

My point is that when you would do that in a very disconnected situation you
would have to clean that before you could serialize that, while that is in a
windowsituation not is necessary.

I see nothing wrong when you want to make a basic dataset which contains all
data for general use in the most common situations.

It is of course forever good thinking what you are doing, taking all columns
in a dataset with 100000 rows is different from taking one column . However
when it are one or two rows than I would not think to long about it.

It is an approach, when there was only one good approach there would not
have been the possibility to choose.

Just my thougth,

Cor

I agree it is always better to have only necessary columns then all the
columns... also the approach to include all the tables in one dataset is i
believe the more cleaner and logically understandable as it closely
resembles the Database. It also adds up to the benifits when using
DataRelations..

Manu