DataReader vs DataSet

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have read some articles state that DataSet should NOT be used for large
resultset. What does "large" mean? Is "large" based on # of rows/columns
and/or memory required to hold the original and the changed?
I'm using VS2005 with .net 3.0.
 
It's really based on the memory available on your server to client machine.
You need to remember that DataSets are "in memory" while the DataReader is a
direct readonly, forward only connection to the data source.

The issue with the DataReader is that as long as you are using it, you are
using a connection. Not good if you have a limited number of connections.
Usually, DataReaders should be used for smaller result sets.

Does that help?

======================================
David McCarter [Microsoft VB.NET MVP]
www.vsdntips.com
VSDN Tips & Tricks .NET Coding Standards available at:
www.cafepress.com/vsdntips.20412485
 
Short answer Yes to all :-)

However what is large ? in the previous company i worked ( a automotive
data provider ) everything bigger as 8 Million was large in the current
company i work for everything above a few thousand records is considered
large .

In the case of a Windows desktop application , i would say show only to the
user what they can handle , showing hundreds of records in a datagrid is
in my opinion foolish and by me considered as poor design .

If you have a large result set , then use Server side data paging actually
in my current proggy`s search engine i only show 10 records at a time
result is a super fast user experience however this does require som T-Sql
knowledge .


HTH

Michel
 
Peter said:
I have read some articles state that DataSet should NOT be used for large
resultset.
Click to expand...

That's correct. If you use a DataSet, all the data has to be in memory
at the same time.
What does "large" mean? Is "large" based on # of rows/columns
and/or memory required to hold the original and the changed?
Click to expand...

Both, but not only that.

There are some overhead for each row, so even if you have very little
data in each row, a lot of rows means a lot of data.

What you should also consider is how much data there might be in the
future. Systems tend to grow over time. Reading all users into a DataSet
is no problem when the are a hundred of them, but what happens when you
have 10000 users, or a million?
 
Peter,

For me the first criteria is, is it only for showing or as well for
updating, in the last case I would choose for small dataset in the way
Michel wrote.

Secondly is it for WindowsForms or is it for ASPNet, a datareader works fine
in ASPNET however needs more work in WindowsForm.

Cor
 
Hi Cor,

It is for showing only and in Windows Forms. However, the # of rows are
unknown since it varies depending on which functions of an application are
running and it can increase substantially since they can be transaction data.


Peter
 
It is for showing only and in Windows Forms. However, the # of rows
are unknown since it varies depending on which functions of an
application are running and it can increase substantially since they
can be transaction data.
Click to expand...

AFAIK The Dataset uses a datareader internally which proves that it is faster.


As mentioned before it is a readonly forward only cursor. - so as long as
your happy with not updating through it you're fine.

As a Datareader is only a pointer to the current record, It does not hold
the entire result set in memory.

A Dataset uses a Datareader to load each and every row of the result into
memory. This can be a concern. More so on an ASP.net, less so in Windows
forms.

Some controls can't databind with a Datareader

Datareader = faster, less memory usage, and simpler(less capable)
Dataset = Slower, more memory but more capable.

I hope this helps
 
Back
Top