Dataset confusion?

[Guest]

Dear all,

I have read in many places that datasset are great for retriving data that
needs to be updated afterwards as they are working as discinnected mode.
But then an other topic comes is the fact that they are expensive in memory...

So now my question is that:
if you have a huge amount of data issu from a single table or linked
tables, you know that you need to make records update at a certain point. At
first Dataset is the proper way of doing it, but when people says that
dataset are expensive in memory what to do then, or when to use it ?

Thanks to clear upmy mind on that
Regards
serge

 

[Marina]

If you have large amounts of data, storing it in memory is going to be
expensive no matter what. That doesn't mean that datasets are ridiculously
more expensive as far as memory goes. It's just that the comment usually
takes place in the context of someone saying they are retriving 50K records
or something and storing it in a dataset.

 

[Robbe Morris [C# MVP]]

DataSets are like mini databases in memory. You can do all sorts
of things with "if necessary" such as parent/child relationships, cross
table
relationships (a DataSet holds one or more DataTable), and various other
items.

In a desktop app, they can work well for databinding to grids, lists, etc.
particularly
if you need a do/undo mechanism prior to commiting all the changes to the
database. I generally only utilize DataSets for managing database updates
when
I want to work with a whole set of related records. Otherwise, I stick with
the standard approach of calling stored procedures on individual records
using my own custom code.

That said...

If you are simply querying records for display, you'll want to look at
filling
a DataTable or just using a Reader. Far less overhead.

--
2004 and 2005 Microsoft MVP C#
Robbe Morris
http://www.masterado.net

Earn $$$ money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp

 

[Guest]

thanks marina,

So whatever the amount of records as soon as we know that update of recrds
will go soon or later, dataset object is the only way ...

 

[Guest]

serge,

No, datasets are not required for updating of records.

Any technique that handles concurrency issues will work. Of course, datasets
have some built-in methods of handling concurrency that you can take
advantage of.

Kerry Moorman

 

[Guest]

Yes that was what I was in mind when saying that they are the only way based
on the big adavtage they gets such as updating only what has been change and
also the fact that they handle by themselves the connection object when
needed.

 

[Sahil Malik [MVP]]

Serge,

The other choice is to use Custom business objects.

Here is a good discussion on Custom Business Objects versus DataSets -

http://codebetter.com/blogs/sahil.malik/archive/2005/06/07/64172.aspx

Saving disconnected hierarchical data is going to be a pain no matter if you
use Datasets or Business objects, but that isn't the fault of either
datasets or BOs.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------

 

[Cor Ligthert [MVP]]

Serge,

As in any OOP solution there is a little bit overhead, that can be gained
not using that. (Mostly the effect is loosed again by the complex methods
that should be used to gain that)

However, it is in my opinion a fool who wants in 2005 on a windows based
system to win some bytes.

A dataset is almost nothing more than a collection of collections that holds
references to objects.
There are some values in it by instance for the name of the dataset itself.

Just my opinion

Cor