Philosophy Datasets vs. Datareaders

  • Thread starter Thread starter Jim Hughes
  • Start date Start date
J

Jim Hughes

I've been following the "Re: DataReader is connected?" thread with interest.

A thought occurred to me... And I would like to hear what others think about
it.

Best practice: Open connections as late as you can, close them as soon as
you can

But rarely do you hear " and keep them open as short a time as possible "

Based on that, it would seem that retrieving data into a dataset would be a
simple, "known" method of retrieving the data in a single full stream.
(Admittedly at the expense of memory at the client)

On the contrary, using a datareader means that the data is read one row at a
time and "processing", perhaps more than simple retrieval, is performed for
each row. It would appear to me that this potentially would keep the
connection to the database open longer!

The benefit of using less memory on the client would then be outweighed by
keeping the connection to the server open longer!

My initial reaction is: "It depends on the circumstances" :)

Thoughts?
 
Yup, if you block the DataReader by doing a bunch of per-row processing,
you're likely to hold the connection open longer. I for one like to do my
per-row processing on the server--especially in cases where I can use a TSQL
procedure to do the work. Yes, it requires a more complex server-side
procedure, but I don't have to move the data to the client just to be able
to use VB to massage the data and then send it back again. Sure, there are
cases where you need to send the data to the client for processing as when
you're sending data points for a drawing or the names of hotels in Cleveland
(perhaps that's not a good example but you get the idea).

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
What if you parse the entire reader directly to a repeater like:
rp.datasource = reader
rp.databind()
reader.close()

Is it still reading each line in the background?

A
 
Jim,

I couldn't help agree with you .. it certainly depends on the circumstances
... there is no magic bullet. You have to go by your judgement.
Funny - everything that is near or around a database is more and more like
that. You just can't write a tool to create the best possible code and at
times there is no good or bad - just too many grey shades.

That thread - admittedly was awesome.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Jim,

A DataSet will use up more bandwidth also -- pretty important factor. The
more processing that stays on the SQL server side the better for
performance. DataReaders are very limit. As always, match the
situation/requirements and balance out coding maintenance, and overall
performance.

I've seen and programmed very elegant abstractions, but if you have multiple
developers of various skill/experience levels it could take time for anyone
to understand the abstractions -- and time is always a factor. So, coding
solutions can also require that sometimes one makes minor performance hits
in order to keep code maintenance viable as developers come and go.

One has to keep in mind that the folks writing the books and doing the
documentation are most likely not "real world" developers running multiple
projects at the same time with timelines and money directly on the line (if
they were they probably wouldn't be writing a book). So, everything is a
careful balance with Practical solutions.

Rob.
 
Ah, just because I've written a book or two (actually about 10 at last
count), translated into 6 languages (that I know of), does not mean I don't
describe "real world" development scenarios. I agree though. Many of the
theoretical approaches are tough to implement in a team composed of people
with widely varying backgrounds and experience levels. Virtually all teams
are build like this--from what's available talent-wise. Most of my books
discuss pretty pragmatic "realistic" approaches that a "typical" developer
or team can implement without needing a rocket scientist to assemble, test,
deploy and support.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Rob,

I'm on my second book, and I'm a very real world developer. I work fulltime
for a company as a system architect and I consult for another one in the
evenings for a project that I used to be architect of.

I'm quite real world :) come and touch me !! LOL !!

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
And I have read some of your books.

In most cases developers have to decide on getting it done vs. a work of
art. The majority fall into the "getting it done" category and we all wish
we could have just a little more time to really explore the abstractions and
features. Then there are developers that do explore all the avenues and
spend endless hours and time tweaking it to perfection -- however, the
deliverable was 1 year ago and nobody wants a now outdated solution (and/or
the company has gone out of business).

The only suggestion I have with your books Bill is please don't use the "see
chapter 2 for this code" -- perhaps I am alone on this, but I dive into a
book and find what I need as fast as possible (aka Index, look up keyword).
When looking for a code snippet to demonstrate a practical solution/concept,
I don't wanna have to go back a chapter (sometimes several) to look at that
sample -- I end up going back and forth like a ping pong ball. I know this
is easier for you/publishers, but a book shouldn't be about you, it should
be what is good for the reader.

To be very honest, I find way TOO much "fluff" (abstract explanations I can
get from MSDN or long winded intros) in most of the books I've read. What I
want, is code samples, lots and lots and lots of code samples -- you can
reference CD sources or web site sources, but I bought the book and I want
my hard copy sample IN the book -- please :) -- choose small fonts or
whatever, but just put it in the book as a complete sample. Since these
books go for $60-$70 a pop, put those 700-1000 pages to good use.

Rob.
 
Here's a thought.....
Download Anakrino ... it lets you decompile the base classes....see what a
Data Adapter actually does.
You'll find out that it does an execute reader, executes Add(object[]) on
the datatable for each Read, then closes the dataset.

So indirectly, you're using a datareader.
 
Jim Hughes said:
My initial reaction is: "It depends on the circumstances" :)

Thoughts?
Click to expand...

Thanks for all of your replies, it seems like my initial reaction is right
on! :)
 
DataReader:

DataReader is a class which class object will have the set of
records returned from the database. DataReader object can iterates the
records in the DataReader object one by one that too only forward and
readonly manner. You cannot update/delete the records in the DataReader
object. DataReader object can identify the number of columns returned by
executing query. One thing to note about the DataReader is, it will have the
records returned by executing a query, not the table structure/schema.

DataSet


About DataSet, Microsoft documentation says that disconnected database(!).
With DataSet, you can copy the data in the database to the DataSet, then it
will be isolated from the database. DataSet can store Tables, Rows, Columns,
Relations, Constraints etc. But one thing about DataSet, it is a class,
handled by the .NET Framework. So you cannot query the Dataset object by
using SQL commands. But You can query the DataSet object by using object find
mechanism, you can add tables in to DataSet in terms of objects, you can add
columns to DataTables interms of objects, you can insert values for tables
with out using any SQL Query but by using .NET Framework library. You can
free to use all the collection classes with the DataSet.

So you can say that DataSet provides you RDBMS functionalities but it
doesnot have any REBMS engine (process). So DataSet will be put in to your
application process and you can give security and access to the dataset as
much you can.

I hope I catch the point. I would like to get some more about this. Anyone
pls :).

Thanks & Regards,

Gopal,
Bangalore,
India
 
Gopal said:
I hope I catch the point. I would like to get some more about this.
Anyone pls :).
Click to expand...

You're generally right here.

I think of a DataSet as a collection of records. It's just a container
for working on a small amount of data at one time. You don't want to
keep thousands of records in a DataSet.

You move a small amount of data from the DB into a DataSet so you can
work on it in an interactive manner. Then, you can move the changed
rows back to the DB.

The DataReader gives you a LIVE connection to read records from the DB.
This is good if you have to process a lot of records and you don't want
to keep them all in memory.

Eric
 
Back
Top