Datasets - use 1 or many?

  • Thread starter Thread starter Ryan
  • Start date Start date
R

Ryan

I'm learning when it comes to Datasets. Should I just have a single dataset
to handle my entire application data or should I use multiple - a dataset
for each function or form within my application? Is the data actually
written from and queried to the dataset only when needed per a table
adapter? It looks like the table adapters .fill method is only invoked when
required, so I assume a single dataset would suffice. Is this right?

Thanks,
Ryan
 
The Fill method is only invoked when you invoke it - so it is up to you to
only do it at the right times.

There is no one right answer, but given very few details as to the nature of
your app, I would say a safe thing to do is to have 1 for each form. Once a
form is closed, you don't want something in your application holding on to
that data or still keeping it around. Each form should be able to deal with
its own data, and shouldn't need to know about data that belongs to other
forms.
 
Thanks. This is actually the way I started setting up my project (one
dataset per form). Since each form should need access to at most 4-5 tables
and I didn't want to include all 20+ tables in a single dataset.

Ryan
 
Hi Ryan,

In addition, I suggest you put all relational tables in a DataSet. There is
no requirement for using how many DataSets on a form. It's just for your
convenience, which makes the developer clear of relations between tables.
HTH.

Kevin Yu
Microsoft Online Community Support

============================================================================
==========================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
============================================================================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Ryan,

One single dataset will probably be very inefficient. Where you cut it is up
to you. Version 2005 goes back to the datatable (the equivalent of the
recordset) approach. Although that is for external reasons always wrapped
inside a dataset.

I hope this gives an idea, do you want to know more specific things, than
reply

Cor
 
Kevin and Marina,

I had not seen that you both had answered already while replying.

Probably something in my eyes.

:-)

Others I had written "in addition".

So by this.

Cor
 
Just to give you all an example of one of my forms and an idea of what type
of dataset I need:

I have an application form which displays an application sent in by a person
(applying for a position on a public board). The form needs to display
information from all of the following relational tables:

The Person table containing contact information for that person.
The Application table containing general information about the application
(when and how it was submitted)
The Application_mm_Board table which contains a record for each board this
application is being submitted for.
The Board table which is needed for the name of each board the applicant is
applying for.
The Application_mm_Question table which contains a record for each question
asked on this application
The ApplicationQuestion table which stores the questions themselves.
The ApplicationAnswer table which stores the applicants answers to each
question.
The User table which shows who submitted this application if it was input
manually by a user.

As you can see a even a single dataset for this one form becomes rather
large. Do you think I should split it up even further for different
functions on the form? Maybe a different dataset for separate datagridviews
on the form?

Thanks,
Ryan
 
Ryan,

I would create datasets containing the main table (have a look at paging so
that you can limit them in lenght) and supporting tables. Probably do you in
most cases only need the name from the user, so loading that with all its
data is a waste of time. I assume that the user table contains probably only
the extra data not in the person data. Probably do you need that data
nowhere except there where you modify that and to logon, so it can probably
only contains forever only one row that you have selected with a where
clause (I don't know if you do it already however try to use
uniqueindentifiers which are Guids).

Probably is a lot related round a user, than try to get only the data from
that user with a where clause in your dataset.

(In my idea does a datasets not reflect your organisation as a database
does. A dataset is for me reflecting the way your data is used)

Just my thoughts,

Cor
 
Yea actually the User table is only needed as a lookup table to find the
User name (users are backend users of the application, not applicants which
are stored in the person table). So would you suggest putting lookup tables
in datasets by themselves (for drop-down boxes usually)? Since lookup
tables usually only need one or two fields from a table.

Ryan

Cor Ligthert said:
Ryan,

I would create datasets containing the main table (have a look at paging
so that you can limit them in lenght) and supporting tables. Probably do
you in most cases only need the name from the user, so loading that with
all its data is a waste of time. I assume that the user table contains
probably only the extra data not in the person data. Probably do you need
that data nowhere except there where you modify that and to logon, so it
can probably only contains forever only one row that you have selected
with a where clause (I don't know if you do it already however try to use
uniqueindentifiers which are Guids).

Probably is a lot related round a user, than try to get only the data from
that user with a where clause in your dataset.

(In my idea does a datasets not reflect your organisation as a database
does. A dataset is for me reflecting the way your data is used)

Just my thoughts,

Cor

Ryan said:
Just to give you all an example of one of my forms and an idea of what
type of dataset I need:

I have an application form which displays an application sent in by a
person (applying for a position on a public board). The form needs to
display information from all of the following relational tables:

The Person table containing contact information for that person.
The Application table containing general information about the
application (when and how it was submitted)
The Application_mm_Board table which contains a record for each board
this application is being submitted for.
The Board table which is needed for the name of each board the applicant
is applying for.
The Application_mm_Question table which contains a record for each
question asked on this application
The ApplicationQuestion table which stores the questions themselves.
The ApplicationAnswer table which stores the applicants answers to each
question.
The User table which shows who submitted this application if it was input
manually by a user.

As you can see a even a single dataset for this one form becomes rather
large. Do you think I should split it up even further for different
functions on the form? Maybe a different dataset for separate
datagridviews on the form?

Thanks,
Ryan

Cor Ligthert said:
Kevin and Marina,

I had not seen that you both had answered already while replying.

Probably something in my eyes.

:-)

Others I had written "in addition".

So by this.

Cor

"Kevin Yu [MSFT]" <[email protected]> schreef in bericht
Hi Ryan,

In addition, I suggest you put all relational tables in a DataSet.
There is
no requirement for using how many DataSets on a form. It's just for
your
convenience, which makes the developer clear of relations between
tables.
HTH.

Kevin Yu
Microsoft Online Community Support

============================================================================
==========================
When responding to posts, please "Reply to Group" via your newsreader
so
that others may learn and benefit from your issue.
============================================================================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
Click to expand...
Click to expand...
Click to expand...
 
Yes

And if they change and you have too the complete information in a where
table, than change that table too and don't update it.

Cor

Ryan said:
Yea actually the User table is only needed as a lookup table to find the
User name (users are backend users of the application, not applicants
which are stored in the person table). So would you suggest putting
lookup tables in datasets by themselves (for drop-down boxes usually)?
Since lookup tables usually only need one or two fields from a table.

Ryan

Cor Ligthert said:
Ryan,

I would create datasets containing the main table (have a look at paging
so that you can limit them in lenght) and supporting tables. Probably do
you in most cases only need the name from the user, so loading that with
all its data is a waste of time. I assume that the user table contains
probably only the extra data not in the person data. Probably do you need
that data nowhere except there where you modify that and to logon, so it
can probably only contains forever only one row that you have selected
with a where clause (I don't know if you do it already however try to use
uniqueindentifiers which are Guids).

Probably is a lot related round a user, than try to get only the data
from that user with a where clause in your dataset.

(In my idea does a datasets not reflect your organisation as a database
does. A dataset is for me reflecting the way your data is used)

Just my thoughts,

Cor

Ryan said:
Just to give you all an example of one of my forms and an idea of what
type of dataset I need:

I have an application form which displays an application sent in by a
person (applying for a position on a public board). The form needs to
display information from all of the following relational tables:

The Person table containing contact information for that person.
The Application table containing general information about the
application (when and how it was submitted)
The Application_mm_Board table which contains a record for each board
this application is being submitted for.
The Board table which is needed for the name of each board the applicant
is applying for.
The Application_mm_Question table which contains a record for each
question asked on this application
The ApplicationQuestion table which stores the questions themselves.
The ApplicationAnswer table which stores the applicants answers to each
question.
The User table which shows who submitted this application if it was
input manually by a user.

As you can see a even a single dataset for this one form becomes rather
large. Do you think I should split it up even further for different
functions on the form? Maybe a different dataset for separate
datagridviews on the form?

Thanks,
Ryan

Kevin and Marina,

I had not seen that you both had answered already while replying.

Probably something in my eyes.

:-)

Others I had written "in addition".

So by this.

Cor

"Kevin Yu [MSFT]" <[email protected]> schreef in bericht
Hi Ryan,

In addition, I suggest you put all relational tables in a DataSet.
There is
no requirement for using how many DataSets on a form. It's just for
your
convenience, which makes the developer clear of relations between
tables.
HTH.

Kevin Yu
Microsoft Online Community Support

============================================================================
==========================
When responding to posts, please "Reply to Group" via your newsreader
so
that others may learn and benefit from your issue.
============================================================================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
Click to expand...
Click to expand...
Click to expand...
 
Back
Top