Porque usar un DataSet pudiendo emplear el DataReader?

24/01/2005 - 23:59 por Juan Pedro Gonzalez | Informe spam
Hola,

No entiendo muy bien porqeu todas las preguntas relacionadas con bases de
datos van orientadas al uso de los DataSets. Si alguien me puede explicar
porque se usan tanto lo agradecería.

Desde mi punto de vista... El DataSet es mas lento que el DataReader, y solo
por ese detalle el DataReader se suele convertir en mi primera opcion.
Ademas el DataReader va cargando una fila cada vez que se la pedimos, por lo
que emplea muchos menos recurso que un DataSet, lo que tambien me hace
inclinarme por el DataReader.

Teniendo en cuenta estos detalles se me ocurre que el DataSet puede ser de
utilidad cuando tenemos una mala conectividad y poemos sacrificar recursos
de la maquina.

En ocasiones el uso del DataReader puede ser mas complicado, ya que tenemos
que diseñar una consulta que resulte efectiva y rapida, ya que el DataReader
sólo nos permite emplear la conexion para el DataReader hasta que lo
cerremos, y solo podemos recorrerlo de forma secuencial hasta el final. El
DataSet al tener los datos en memoria nos permite recorrerlo en cualqueir
dirección. Aun asi con un buen diseño y planificacion podemos recorrer un
DataReader para cargar los datos de un ComboBox, ListBox, ListView, etc... y
de mas rapidamente que con el DataSet.

Puede existir alguna ocasion en la que nos salga mas rentable ocupar memoria
y poder recorrer una lista de resultados una y otra vez por algun motivo, en
cuyo caso el DataSet sería mas afortunado... Tambien nos puede venir bien el
DataSet si queremos descargar un poco la red, ya que el DataSet se
desconecta en cuanto ha recuperado los datos de la base de datos.

Otro motivo interesante, es que el DataReader no puede pasar los datos de la
respuesta a otro formulario ya que, como se ha mencionado, solo contendrá
una fila de todos los resultados (Lo que no impide que se pase la
referencia, pero por ejemplo en ASP con cambios de paginas esto no es
posible), aun asi deben ser consultas no muy extensas... Vamos, que no
podemos pasar todo el stock de un almacen como un dataset porque la cantidad
de datos que se va a generar pueden ser enormes.

Por otro lado nos puede interesar una conexion persistente, y segun tengo
entendido el DataSet cierra la conexion en cuanto ha recuperado los datos.

Quizas se podria seguir hablando de diferentes aplicaciones para cada uno, e
incluso cuando es mejor almacenar los datos en una base de datos local como
Access antes que emplear el DataSet para recoger gran cantidad de datos y
demas...

Pero ¿alguien me puede decir que ventaja le ve a cargar un Combo con un
dataset generado por una consulta sencilla?

Creo que aqui tiene mucho que ver DJMIAO, ya que los libros parecen estar
repletos de ejemplos con DataSets y mas DataSets, e incluso en las academias
y facultades parece que se le da una importancia increible al DataSet...
Incluso he oido rumores que dicen que los profesores aconsejan usar siempre
un DataSet, y que algunos libros hacen lo mismo. ¿Que ventaja tiene usar
siempre un DataSet? Personalmente en un mundo real le veo mas ventajas al
DataReader que al DataSet (Lo que no quita que a veces sea mejor recurir al
DataSet). Vamos, yo no me imagino los Pentium 350 con 128 Mb de RAM y
Windows 2000 Profesional o incluso Windows XP, trabajando con un CRM que se
trae toda la lista de contactos atraves de un DataSet... o un ERP trayendose
todos los pedidos del mes atraves de un DataSet.

Teruel existe! ...y el DataReader tambien!

Saludos

Preguntas similare

Leer las respuestas

#6 Leonardo Azpurua
25/01/2005 - 15:28 | Informe spam
"DJ MIAO" escribió en el mensaje
news:062f01c502e7$7ccdcc10$
No cambias tratando de imprecionar y nunca contestas
directo. Solo mucha Bla bla bla para despues decir que
usa el que te da la gana.


Por lo menos hablo del tema, no acerca de la otra gente, bobito.
Respuesta Responder a este mensaje
#7 Juan Pedro Gonzalez
26/01/2005 - 00:17 | Informe spam
Por lo que veo tienes una forma de programacion similar a la mia al menos en
bases de datos, a mi tambien me suele gustar emplear mi spropias clases de
bases de datos para tratar de "modularizar" la aplicacion. Las bases de
datos casi siempre las trato en su propia clase, salvo en casos muy
concretos en los que puede necesitar optimizar mas la respuesta del
programa, ya que ahi las funciones genericas no te suelen dar el máximo que
puedes sacar de la aplicacion, aunque por otro lado te da la ventaja de
tener un codigo mas extendido, por lo que un arreglo en la clase se
convierte en un arreglo para todas las aplicaciones (Ahorro de tiempo, y por
lo tanto costes para el cliente).

Saludos




"Leonardo Azpurua" <l e o n a r d o (arroba) m v p s (punto) o r g> escribió
en el mensaje news:e$

"Juan Pedro Gonzalez" escribió en el mensaje
news:%231t%

Hola, Juan Pedro:

En funcion de optimizar el ancho de banda, divido los datos en dos tipos:
estaticos y volatiles.

Los datos estáticos son parametros de uso general, cosas como definiciones
de tipos de impuestos, porcentajes de descuentos otorgados a cada tipo de
cliente, cosas que por lo general cambian poco de valor durante la


ejecución
de un programa. Los datos volatiles, en cambio, son los que estan


cambiando
todo el tiempo.

Cuando tengo conjuntos pequeños de datos "estáticos", normalmente tengo un
miembro estático (Shared) de la clase que los representa, que los almacena
en una coleccion, y una funcion que devuelve esa coleccion. La coleccion


la
lleno, por supuesto, con un DataReader. Si el conjunto de datos es grande,
tengo un miembro Shared de la clase al que le pasas una referencia
"inequivoca" (por lo general una clave primaria) del registro que


necesitas,
y un DataReader lo busca y o devuelve.

Para todo lo que necesito, uso DataReaders (soy un fanatico del
"minimalismo": consumo mínimo de una variedad mínima de recursos: por eso


no
hay manera de que pueda seguir un curso de certificacion).

Pero pensando un poco, se me ocurre que los DataSets son "abstractos":
conozco los oleDBDataReader y los sqlDataReader. Los DataSets son
independientes del proveedor (igual que los oleDBDataReaders, "pero más").
En ese sentido son una representacion abstracta de los datos subyacentes


que
te permiten una separación mas neta entre las capas: no hay un riesgo en
usar un DataSet en los niveles de presentación -siempre que la vinculacion
con la implementacion concreta se realice mas abajo.

Desde que trabajaba con herramientas mas primitivas, siempre


responsabilicé
a las clases "de servicios" del enlace con las BBDD. Por eso no uso ni
datasets ni datareaders en los niveles de aplicacion. Como no es cosa de
cambiar toda la concepcion del oficio cuando cambias de herramienta,


decidí
mantener los mismos principios constructivos generales, y para ello el
DataReader me venia de perlas. Pero imagino que si uno comienza desde cero
con VB.Net, los DataSets son una manera muy cómoda, y muy correcta, de
pasar estructuras de complejas entre componentes. Que uno no vea muy


claras
las ventajas, es otra cosa.

Pero es tardisimo.

Salud!


Respuesta Responder a este mensaje
#8 Juan Pedro Gonzalez
26/01/2005 - 00:22 | Informe spam
Cierto que es una novela muy larga... Aunque lo de cambiar de libro lo
tendria dificil, ya que cuando me plantee comprarme un libro no encontre
ninguno que cubriese todas las necesidades que tenia; asi que decidi que era
mejor ahorrarme el dinero ya que no me veia pagando cuatro libros tecnicos a
treinta euros el libro para leerme un capitulo de cada uno.

Saludos


"DJ MIAO" escribió en el mensaje
news:062e01c502e7$50a15b20$
La novela esta muy larga . Resume lo que necesitas saber.
Por cierto hasta donde lei me di de cuenta que tienes
que cambiar el libro.



Miao..
Comprate un libro.
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida