DataSet Best Practices - One all-purpose dataset? RRS feed

  • Question

    • Environment:
    • VB.NET 2005
    • Local (non-ASP) application
    • Data source is Access MDB on network drive, with frequent schema changes
    • Using Designer to build/maintain data access components
    • Classes (forms) will often show/update data from several tables

    Considering using a dataset containing all tables/table adapters, with each adapter having multiple select, insert, etc queries, each specific to the needs of a particular user (class).

    Is a single giant dataset a bad idea?

    I know that dataset objects will be 'heavy', but instantiation should be limited to one per class (form). Queries will be built to pull only needed data.

    It seems like this would make updating the schema easier (rather than chasing down all datasets accessing a particular table), and also provide the ability for classes to pick and choose their data from across the entire database, potentially without even changing any adapters (if an appropriate one already exists).

    Thank you!

    Friday, February 10, 2006 8:19 PM

All replies

  • I have some opinions on the subject, but I am in no way an expert.  Experts, please correct me where I am wrong.

    As a programmer, I struggle with two basic things during development: 1.) Maintainability 2.) Performance.  I always put maintainability of my code first unless there is an unacceptable trade-off in performance.  If, and only if, the performance degrades to an unacceptable level will I alter the maintainability.  It is my assumption that the single giant dataset will not degrade performance to an unacceptable level so my decision would be to opt for the giant dataset.  I, of course, do not have any proof that this would be the case, only a gut feeling.

    I think that MS made a conscious effort to make the new tableadapters reusable accross multiple controls/components and they advertise this fact.  I think in the past you were forced to use a separate adapter for each control/component.  The pollution to namespaces can get pretty ugly if you create a multitude of datasets.  I prefer to keep it all hidden behind one namespace which means one dataset.

    If I understand typed datasets properly; the datasets you view in the designer are really only visual representations of the schema and have nothing to do with the data.  Data would cause real bloating and you would certainly want to separate things out.  The designer is used to create the classes for the typed datasets.  Of course, the more dataadapters you have in a dataset, the larger the classes will become.  I'm not sure what the additional overhead is to the class by adding additional tableadapters, but you should be able to quantify it.  A new dataset adds approx. 600 to 700 lines of new code to your app.  You could add an additional tableadapter and then check the incremental increase in lines of code. 

    Unless there is reuse in code among datasets, then I'm going to assume that you will get hit with 700 lines of code everytime you create a new dataset.  How does the 700 lines of code compare with the incremental?  Hopefully the incremental for adding a table adapter is considerably less than 700 lines.  How does the number of lines of code effect instantiation?  I don't know the answer to that.  Are there benchmarks out there for such a thing?  Probably

    Wednesday, February 15, 2006 7:12 AM