datareader vs. dataset

[Bihn]

I was reading about datareader which is said to be slimmer & faster then
dataset. Since the datareader have to go fetching the dat from the database
every time it need it, the data it gets then should be up to date. However,
both the IbuySpy and Duwamish samples and most, if not all, the shopping
cart sample codes I've seen use dataset to implement the opration for
ecommerce sites. So is the trip that the datareader need to go fetch the
data from the database is too much a performance drag or is using the
dataset is "the way" to implement the ecommerce site? Will keeping the
information up-to-date present a problem because the dataset is a
disconnected data access control? Anyone who has implemt ecommerce site
please give me opinion as to which data access control is more suitable to
use to implement an ecommerce site.
Thanks.

 

[Lucas Tam]

I was reading about datareader which is said to be slimmer & faster
then dataset. Since the datareader have to go fetching the dat from
the database every time it need it, the data it gets then should be up
to date. However, both the IbuySpy and Duwamish samples and most, if
not all, the shopping cart sample codes I've seen use dataset to
implement the opration for ecommerce sites. So is the trip that the
datareader need to go fetch the data from the database is too much a
performance drag or is using the dataset is "the way" to implement the
ecommerce site? Will keeping the information up-to-date present a
problem because the dataset is a disconnected data access control?
Anyone who has implemt ecommerce site please give me opinion as to
which data access control is more suitable to use to implement an
ecommerce site. Thanks.

The value of a dataset is somewhat diminished in a web environment
because each time the webpage loads the dataset is refreshed anyways. I
prefer to use a datareader whenever possible because:

1. Datareaders use a lot less memory
2. Data readers are faster

Becareful when using a dataset with a large amount of data - you'll suck
up all of the server's resources. Datasets are best for filter/sorting
small sets of data.

 

[Karl Seguin]

This is a half truth. DataSets can be cached while data readers can't,
which nullifies your concern about DataSets....I would consider the
disconnected, and hence cached, nature of datasets the primary factor to
favor them over pure DataReaders. In some situations (even within the same
application) one method is better than the other. In other words the
question is pretty hard to answer since it's very situational.

As for keeping the DataSet up to date, the DataAdapters and DataTable
contain some pretty nice functionality for maintaining state dispite their
disconnected fashion.

There are a lot of alternatives to both DataSets and DataReaders which I'd
highly recommend for large scale systems. I just finished writing an
article which you might find useful:
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/CustEntCls.asp

Karl

 

[bruce barker]

in a e-comm sites datareaders should be avoided for serveral reasons

1) the overhead of a dataset or datatable if single result set is low over a
datareader
2) a dataset will hold read locks for less time than a datareader in most
cases
3) unless you are very careful in wrapping all datareader accesses with
onerror handling to do the close you will have a resource leak.
4) unit tests are easier to write with datasets
5) thru typed datasets you can catch coding error ate compile time
6) its a really bad practice for a function to return a datareader, so it
can be hard to properly structure code

-- bruce (sqlwork.com)




| |
| > I was reading about datareader which is said to be slimmer & faster
| > then dataset. Since the datareader have to go fetching the dat from
| > the database every time it need it, the data it gets then should be up
| > to date. However, both the IbuySpy and Duwamish samples and most, if
| > not all, the shopping cart sample codes I've seen use dataset to
| > implement the opration for ecommerce sites. So is the trip that the
| > datareader need to go fetch the data from the database is too much a
| > performance drag or is using the dataset is "the way" to implement the
| > ecommerce site? Will keeping the information up-to-date present a
| > problem because the dataset is a disconnected data access control?
| > Anyone who has implemt ecommerce site please give me opinion as to
| > which data access control is more suitable to use to implement an
| > ecommerce site. Thanks.
|
|
| The value of a dataset is somewhat diminished in a web environment
| because each time the webpage loads the dataset is refreshed anyways. I
| prefer to use a datareader whenever possible because:
|
| 1. Datareaders use a lot less memory
| 2. Data readers are faster
|
| Becareful when using a dataset with a large amount of data - you'll suck
| up all of the server's resources. Datasets are best for filter/sorting
| small sets of data.
|
| --
| Lucas Tam ([email protected])
| Please delete "REMOVE" from the e-mail address when replying.
| http://members.ebay.com/aboutme/coolspot18/

 

[Chris R. Timmons]

"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in

I just
finished writing an article which you might find useful:
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-u
s/dnaspp/html/CustEntCls.asp

Karl,

Nice article, but I draw the line at "demoralizing" my database !

(look for the phrase "demoralization for performance"...)

 

[Matt Berther]

Hello Karl,

There are a lot of alternatives to both DataSets and DataReaders which
I'd highly recommend for large scale systems. I just finished writing
an article which you might find useful:
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dna
spp/html/CustEntCls.asp

Thank you for an absolutely wonderful argument and some very compelling reasons
to use entity objects. I've known that this is the right way to go for a
while. Your article though will help to convince my co-workers. :=)

 

[Lucas Tam]

DataSets can be cached while data readers can't,
which nullifies your concern about DataSets....

Is caching provided out of the box in .NET?

And how much memory would a large dataset use?

 

[Karl Seguin]

Hahah...thx I've asked for it to be fixed...I do that all the
time...normally my gf picks it up...I should take the word "demoralize" out
of Word's dictionary and then it'll complain

Karl

 

[Karl Seguin]

Lucas:

Yes, you can use Page.Cache.Insert("someKey", someValue)

and you can specify all types of parameters such as dependencies, time,
priority...

Your 2nd question is impossible to answer...really, how large as we talking?
It isn't just a matter of rows but also of how much information in those
rows....

Karl

 

[Kevin Spencer]

It takes a DataReader to create a DataSet. You never see it (it's
encapsulated), but it's there. So, obviously, the DataReader is going to be
faster than the DataSet. HOWEVER,

1. Speed isn't everything. DataReaders have persistent connections, so they
can't be cached. Fetching the same data twice is going to be more expensive
than fetching it once and caching it, regardless.
2. You didn't mention DataTable. A DataSet is comprised of one or more
DataTables. Therefore, a DataTable has less overhead than a DataSet. Unless
you need all the functionality of a DataSet, a DataTable is faster for
cached data.
3. Sample code doesn't usually indicate the best way of doing something. Its
purpose is to demonstrate technology. The reasons for using different types
of classes might be as simple as wanting to introduce you to one or more of
them. You can't rely on Sample code to recommend technique.

In conclusion, you might just as well ask which gear in your transmissin is
"better." At 5 miles per hour, the high gears aren't going to push the car.
At high speeds, the low gears will rip apart the transmission. It's the same
with DataSets, DataTable, and DataReaders. Obviously (to me) Microsoft
created all 3 data containers for a reason, and anticipated that, at one
time or another, all of them would be useful. The best one is the one that
is best in the current situation.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Lucas Tam]

Yes, you can use Page.Cache.Insert("someKey", someValue)

Oh... never thought of using Page.Cache to cache a dataset. Hmmm good idea.

Your 2nd question is impossible to answer...really, how large as we
talking? It isn't just a matter of rows but also of how much
information in those rows....

I use datasets as little as possible because when I found that I need to
display more than a couple thousand rows of data (i.e. a report) the
dataset gobbles up all the memory on the server. If you page a dataset on
the SQL server side (i.e. with SQL), then don't you lose the benefits of
caching because the dataset would have be refreshed on a per page basis
anyways?

 

[Karl Seguin]

I think you aer mostly right...it's very situational though. You could
cache the entire dataset and use a DataView with the filter to page it
within your code...thus allowing you to cache all the data and then simply
bind items 1-10 (page 1)....all the data might be too much to cache
though...it could be gigabites....dunno...

karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)

 

[Guest]

I was reading about datareader which is said to be slimmer & faster then
dataset. Since the datareader have to go fetching the dat from the database
every time it need it, the data it gets then should be up to date. However,
both the IbuySpy and Duwamish samples and most, if not all, the shopping
cart sample codes I've seen use dataset to implement the opration for
ecommerce sites. So is the trip that the datareader need to go fetch the
data from the database is too much a performance drag or is using the
dataset is "the way" to implement the ecommerce site? Will keeping the
information up-to-date present a problem because the dataset is a
disconnected data access control? Anyone who has implemt ecommerce site
please give me opinion as to which data access control is more suitable to
use to implement an ecommerce site.
Thanks.

Hi, ive led development of large scale ecommerce site (millions of hits/day)
and think that DataSets are the way to go, for following reasons (all IMO of
course):

1. raw performance superiority of the DataReader is unimportant in context
of ecommerce internet apps, where there are many other factors that determine
user-percieved responsiveness.
2. Typical ecommerce pages do not use thousands or even hundreds of rows of
data at a time (if designed correctly, ie. paging done within SPs or the
like). So DataSets in ecommerce world are usually small enough not to cause
alarm in terms of memory.
3. You (and all the developers who build code for your server) need to be
very careful about correctly handling DataReaders in order to avoid memory
leaks. One sloppy dude can ruin everyone's day on that server, and this kind
of error is a nightmare to nail down.
4. DataSets are incredibly easy to work with, esp. with XML and/or XSLT.
And its very easy to look at contents of DataSet during debugging.
5. "disconnectedness" isnt a problem. Just create the DataSet when you are
about to use it. But if you want to use it disconnected, thats cool too,
just cache it.
6. During development you can easily create "fake" DataSets from a data
access layer, without waiting for the DB schema to be finalized or the SPs to
be coded. This enables user-interface coding to proceed without waiting for
the "data team" to get their stuff together.

I can tell you that even with very, uh, "unoptimized" coding, we never had a
problem with performance (avg 1 sec response time). In fact, some of the
main issues which caused outages were related to memory leaks related to
improper handling of DataReaders. I think focusing on the raw speed is
wrong. Think of it this way:
1. would you rather tell a client that your system has a lot of features
because its easy/cheap to maintain and enhance,
2. or, would you rather explain to the client that, yes, your ecommerce site
was down for the day (losing $$$), and yes its taking a long time for the
programmers to add new features you want (spending $$$)... but hey did you
notice that every page request is 0.1 seconds quicker because we're using
DataReaders??

HTH

 

[matt vaughn]

Karl,
I have read your new article with great interest. We have a system
developed using typed DataSets exclusively. We have almost no "real"
business layer in our application (they return a TDS from the DAL.

We have seen some significant performance issues with this configuration
(no cacheing is involved); I'd like to have more of your thoughts on the
distince DAL/BAL using the custom entity approach as described in your
article.

Some questions:
1. should the entitity object setup its own properties using data
returned from the DAL...or
2. how would you implement the data access and mapping using a separate
class.

Thanks!

 

[Eric]

We use the CSLA architecture, which includes an excellent approach for
mapping database access into business objects. It's described in a
book:

http://www.lhotka.net/ArticleIndex.aspx?area=CSLA .NET

and the source code is available. We use it successfully in very large
projects, and get excellent performance.