Datatable vs Recordset

"Emillen Uriarte" wrote in message
news:

Hola a todos, estoy trabajando en un proyecto nuevo en .Net basado en una
aplicación ya existente de Vb6.
Trabajando con Datatables y datasets me he dado cuenta de que el tiempo de
carga de un datatable es muy superior al de un recordset cuando el volumen
de datos es muy grande.
En ambos casos se ataca a la misma Bd de sql server.
Es esto normal, o es que estoy utilizando de manera incorrecta los
datatables etc..??

Efectivamente, es una forma incorrecta. Si el volumen de datos es muy
grande, no se deben cargar en un DataTable. El DataTable mantiene en memoria
una copia de todos los datos que le cargas, con lo cual, en cuanto se queda
escaso de memoria, se pone a usar el archivo de intercambio en disco y se
vuelve lento.
Lo que deberías es usar un DataReader, que es lo más parecido en ADO.Net
al RecordSet de ADO cuando se utiliza en modo solo lectura, solo marcha
alante, y cursor en el lado servidor, que es su modo de funcionamiento más
rápido. Con Sql Server no he hecho pruebas comparativas, pero probando
contra un mdb, en las pruebas que yo hice resultaba considerablemente más
rápido el DataReader que el Recordset.

Cuando dices DataReader te refieres a System.Data.SqlClient.SqlDataReader
??
Por lo que estoy viendo en la ayuda esto es lo único que me aparece, pero no
me vale porque esto si no me equivoco solo vale para bases de datos
sqlserver no es así?? Me gustaria tener una puerta abierta a cambiar de base
de datos.

gracias


"Alberto Poblacion"
escribió en el mensaje news:evLpU%

"Emillen Uriarte" wrote in message
news:

Hola a todos, estoy trabajando en un proyecto nuevo en .Net basado en una
aplicación ya existente de Vb6.
Trabajando con Datatables y datasets me he dado cuenta de que el tiempo
de carga de un datatable es muy superior al de un recordset cuando el
volumen de datos es muy grande.
En ambos casos se ataca a la misma Bd de sql server.
Es esto normal, o es que estoy utilizando de manera incorrecta los
datatables etc..??

Efectivamente, es una forma incorrecta. Si el volumen de datos es muy
grande, no se deben cargar en un DataTable. El DataTable mantiene en
memoria una copia de todos los datos que le cargas, con lo cual, en cuanto
se queda escaso de memoria, se pone a usar el archivo de intercambio en
disco y se vuelve lento.
Lo que deberías es usar un DataReader, que es lo más parecido en
ADO.Net al RecordSet de ADO cuando se utiliza en modo solo lectura, solo
marcha alante, y cursor en el lado servidor, que es su modo de
funcionamiento más rápido. Con Sql Server no he hecho pruebas
comparativas, pero probando contra un mdb, en las pruebas que yo hice
resultaba considerablemente más rápido el DataReader que el Recordset.

Hola!

A ver, dado que el DataReader requiere una conexion conectada a la BD,
evidentemente hay una implementacion para cada tipo de conexion que se
utiliza: SqlDataReader, OleDbDataReader, etc.
Evidentemente dependen de la base de datos utilizada. De todas formas,
puedes valerte del interfaz para no depender del tipo de objeto
instanciado: IDataReader. Por ejemplo:

Public Interface IUniversalData
...
IDataReader ObtenerReader (string strSQL);
...
End Interface

Habra una clase orientada a las conexiones SQLServer:

Public Class CSQLServerData
Implements IUniversalData, IDisposable
...
Public Overridable IDataReader ObtenerReader(ByVal strSQL As
String) Implements IUniversalData.ObtenerReader
Dim oCmd As SqlCommand = New SqlCommand

' Ejecutar el comando
oCmd.CommandText = strSQL
oCmd.Connection = m_objConnection
oCmd.CommandType = CommandType.Text
return oCmd.ExecuteReader(CommandBehavior.Default)
End Sub
...
End Class

Y de una manera muy similar otra con el OleDb:

Public Class COleDbData
Implements IUniversalData, IDisposable
...
Public Overridable IDataReader ObtenerReader(ByVal strSQL As
String) Implements IUniversalData.ObtenerReader
Dim oCmd As OleDbCommand = New OleDbCommand

' Ejecutar el comando
oCmd.CommandText = strSQL
oCmd.Connection = m_objConnection
oCmd.CommandType = CommandType.Text
return oCmd.ExecuteReader(CommandBehavior.Default)
End Sub
...
End Class

Asi, cuando te conectes a la BD, al principio de la aplicacion, tu
defines un objeto global de conexion:
IUniversalData g_objData;

Y lo creas segun sea una conexion SQLServer:
g_objData = New CSQLServerData()

u OleDb:
g_objData = New ColeDbData ()

A partir de aqui, te da igual la base de datos que utilices:

IDataReader dr = g_objData.ObtenerReader ("SELECT * FROM Clientes");
While(dr.Read)

End While
dr.Close() ' Solo puede haber un DataReader abierto por conexion.
dr = Nothing

Creo que en NET 2.0 hay un nuevo sistema de independizar las conexiones
a la BD. Vamos, creo que la capa que yo denomino IUniversalData ya esta
hecho dentro del Framework, pero ahora mismo desconozco el tema... a lo
mejor alguien de la lista?.

Pero vamos, con lo que te he contado no es muy complicado independizar
la BD del codigo de la aplicacion para poder usar de una manera
sencilla diversos proveedores de datos.

Saludos
Roberto M. Oliva


public class CD


message

> news:
>> Hola a todos, estoy trabajando en un proyecto nuevo en .Net basado en una
>> aplicación ya existente de Vb6.
>> Trabajando con Datatables y datasets me he dado cuenta de que el tiempo
>> de carga de un datatable es muy superior al de un recordset cuando el
>> volumen de datos es muy grande.
>> En ambos casos se ataca a la misma Bd de sql server.
>> Es esto normal, o es que estoy utilizando de manera incorrecta los
>> datatables etc..??
>
> Efectivamente, es una forma incorrecta. Si el volumen de datos es muy
> grande, no se deben cargar en un DataTable. El DataTable mantiene en
> memoria una copia de todos los datos que le cargas, con lo cual, en cuanto
> se queda escaso de memoria, se pone a usar el archivo de intercambio en
> disco y se vuelve lento.
> Lo que deberías es usar un DataReader, que es lo más parecido en
> ADO.Net al RecordSet de ADO cuando se utiliza en modo solo lectura, solo
> marcha alante, y cursor en el lado servidor, que es su modo de
> funcionamiento más rápido. Con Sql Server no he hecho pruebas
> comparativas, pero probando contra un mdb, en las pruebas que yo hice
> resultaba considerablemente más rápido el DataReader que el Recordset.
>
>
>

Muchas gracias a los dos. Me queda hacer unas comprobaciones pero he pasado
de 30 segundos en hacer una consulta a 3 segundos gracias al DataReader.

Un saludo.

escribió en el mensaje
news:
Hola!

A ver, dado que el DataReader requiere una conexion conectada a la BD,
evidentemente hay una implementacion para cada tipo de conexion que se
utiliza: SqlDataReader, OleDbDataReader, etc.
Evidentemente dependen de la base de datos utilizada. De todas formas,
puedes valerte del interfaz para no depender del tipo de objeto
instanciado: IDataReader. Por ejemplo:

Public Interface IUniversalData
...
IDataReader ObtenerReader (string strSQL);
...
End Interface

Habra una clase orientada a las conexiones SQLServer:

Public Class CSQLServerData
Implements IUniversalData, IDisposable
...
Public Overridable IDataReader ObtenerReader(ByVal strSQL As
String) Implements IUniversalData.ObtenerReader
Dim oCmd As SqlCommand = New SqlCommand

' Ejecutar el comando
oCmd.CommandText = strSQL
oCmd.Connection = m_objConnection
oCmd.CommandType = CommandType.Text
return oCmd.ExecuteReader(CommandBehavior.Default)
End Sub
...
End Class

Y de una manera muy similar otra con el OleDb:

Public Class COleDbData
Implements IUniversalData, IDisposable
...
Public Overridable IDataReader ObtenerReader(ByVal strSQL As
String) Implements IUniversalData.ObtenerReader
Dim oCmd As OleDbCommand = New OleDbCommand

' Ejecutar el comando
oCmd.CommandText = strSQL
oCmd.Connection = m_objConnection
oCmd.CommandType = CommandType.Text
return oCmd.ExecuteReader(CommandBehavior.Default)
End Sub
...
End Class

Asi, cuando te conectes a la BD, al principio de la aplicacion, tu
defines un objeto global de conexion:
IUniversalData g_objData;

Y lo creas segun sea una conexion SQLServer:
g_objData = New CSQLServerData()

u OleDb:
g_objData = New ColeDbData ()

A partir de aqui, te da igual la base de datos que utilices:

IDataReader dr = g_objData.ObtenerReader ("SELECT * FROM Clientes");
While(dr.Read)

End While
dr.Close() ' Solo puede haber un DataReader abierto por conexion.
dr = Nothing

Creo que en NET 2.0 hay un nuevo sistema de independizar las conexiones
a la BD. Vamos, creo que la capa que yo denomino IUniversalData ya esta
hecho dentro del Framework, pero ahora mismo desconozco el tema... a lo
mejor alguien de la lista?.

Pero vamos, con lo que te he contado no es muy complicado independizar
la BD del codigo de la aplicacion para poder usar de una manera
sencilla diversos proveedores de datos.

Saludos
Roberto M. Oliva


public class CD


message

> news:
>> Hola a todos, estoy trabajando en un proyecto nuevo en .Net basado en
>> una
>> aplicación ya existente de Vb6.
>> Trabajando con Datatables y datasets me he dado cuenta de que el tiempo
>> de carga de un datatable es muy superior al de un recordset cuando el
>> volumen de datos es muy grande.
>> En ambos casos se ataca a la misma Bd de sql server.
>> Es esto normal, o es que estoy utilizando de manera incorrecta los
>> datatables etc..??
>
> Efectivamente, es una forma incorrecta. Si el volumen de datos es muy
> grande, no se deben cargar en un DataTable. El DataTable mantiene en
> memoria una copia de todos los datos que le cargas, con lo cual, en
> cuanto
> se queda escaso de memoria, se pone a usar el archivo de intercambio en
> disco y se vuelve lento.
> Lo que deberías es usar un DataReader, que es lo más parecido en
> ADO.Net al RecordSet de ADO cuando se utiliza en modo solo lectura, solo
> marcha alante, y cursor en el lado servidor, que es su modo de
> funcionamiento más rápido. Con Sql Server no he hecho pruebas
> comparativas, pero probando contra un mdb, en las pruebas que yo hice
> resultaba considerablemente más rápido el DataReader que el Recordset.
>
>
>