Interoperabildad con ADO o ADO.NET, he hay un dilema

"Harvey Triana" wrote in message
news:%23Cll$
Mostrar la cita

Estoy escribiendo un software backend de una aplicación que ejecutará
distribuida. Uso C#. Aun no me decido si usar interoperabilidad con ADO o
ADO.NET. En las primeras pruebas que he hecho, se desempeña mejor ADO.
¿Qué opinan Ustedes?

Por cierto, ADO sobre Visual Basic clásico supera el desempeño de ADO
sobre C#. Esto me pone en controversia.

Es raro. Yo he hecho alguna prueba comparando ADO.Net en C# contra ADO
en VB clásico, y el de .Net era tres veces más rápido que el ADO. En este
caso, la prueba la hice contra Access usando el JET Engine via OleDb. Y
usando DataReaders, no DataSets.

En cualquier caso, el desempeño dependerá de cómo utilices el producto,
ya que no son completamente equivalentes. En ADO tienes los Recordsets,
mientras que en ADO.Net tienes los Datareaders. El Datareader es más
eficiente que el Recordset, pero no hace todo lo que hace el Recordset (por
ejemplo, no puedes hacer un MovePrevious). Por otra parte en ADO.Net tienes
el DataSet, que equivale a grandes rasgos a un Recordset desconectado, pero
lo sustituye con ventaja siempre que se use correctamente y bajo las
circunstancias adecuadas. Y aqui está el quid de la cuestión: "usarlo
correctamente". ADO.Net tiene muchas diferencias con ADO, y para sacarle
todo el rendimiento hay que usarlo de distinta forma. Con la condición de
que el diseño de la aplicación se optimice para ADO.Net, funciona
considerablemente mejor que ADO.

Mostrar la cita

Uso SQL Server 2000 ¿Si uso SQL Server 2005 mejorará el desempeño de
ADO.NET sobre ADO?

No. Con Sql 2005 va a funcionar prácticamente igual que con el 2000. El
2005 tiene alguna novedad, como por ejemplo el MARS (múltiples resultados
abiertos sobre la misma conexión) pero mientras no lo utilices expresamente,
va a funcionar igual que la versión anterior.

Hola Alberto.

Por supuesto no hay discusión de que ADO.NET es superior a ADO. Tecnología
nueva es tecnología nueva. ADO.NET. No obstante parece que cuando los
volúmenes de datos son considerables ADO da mejor rendimiento.

Por cierto, comparé DataReader vs Recorset ForwardOnly (dentro de .NET), que
son prácticamente equivalentes.

Saludos y gracias,
<Harvey Triana />

"Alberto Poblacion"
escribió en el mensaje news:
Mostrar la cita

"Harvey Triana" wrote in message
news:%23Cll$
Mostrar la cita

Estoy escribiendo un software backend de una aplicación que ejecutará
distribuida. Uso C#. Aun no me decido si usar interoperabilidad con ADO o
ADO.NET. En las primeras pruebas que he hecho, se desempeña mejor ADO.
¿Qué opinan Ustedes?

Por cierto, ADO sobre Visual Basic clásico supera el desempeño de ADO
sobre C#. Esto me pone en controversia.

Es raro. Yo he hecho alguna prueba comparando ADO.Net en C# contra ADO
en VB clásico, y el de .Net era tres veces más rápido que el ADO. En este
caso, la prueba la hice contra Access usando el JET Engine via OleDb. Y
usando DataReaders, no DataSets.

En cualquier caso, el desempeño dependerá de cómo utilices el producto,
ya que no son completamente equivalentes. En ADO tienes los Recordsets,
mientras que en ADO.Net tienes los Datareaders. El Datareader es más
eficiente que el Recordset, pero no hace todo lo que hace el Recordset
(por ejemplo, no puedes hacer un MovePrevious). Por otra parte en ADO.Net
tienes el DataSet, que equivale a grandes rasgos a un Recordset
desconectado, pero lo sustituye con ventaja siempre que se use
correctamente y bajo las circunstancias adecuadas. Y aqui está el quid de
la cuestión: "usarlo correctamente". ADO.Net tiene muchas diferencias con
ADO, y para sacarle todo el rendimiento hay que usarlo de distinta forma.
Con la condición de que el diseño de la aplicación se optimice para
ADO.Net, funciona considerablemente mejor que ADO.

Mostrar la cita

Uso SQL Server 2000 ¿Si uso SQL Server 2005 mejorará el desempeño de
ADO.NET sobre ADO?

No. Con Sql 2005 va a funcionar prácticamente igual que con el 2000. El
2005 tiene alguna novedad, como por ejemplo el MARS (múltiples resultados
abiertos sobre la misma conexión) pero mientras no lo utilices
expresamente, va a funcionar igual que la versión anterior.

Hola Harvey,

On Wed, 18 Apr 2007 10:04:09 -0500, "Harvey Triana"
wrote:

Mostrar la cita

Por supuesto no hay discusión de que ADO.NET es superior a ADO.

Yo no tengo nada claro que la productividad de ADO.NET sea superior a
la de ADO. Y tengo bastante claro que es inferior a la de Visual Fox,
PowerBuilder y Delphi.

Mostrar la cita

Tecnología
nueva es tecnología nueva.

Hay montones de ejemplos de tecnología nueva que es inferior a
tecnología vieja.

Mostrar la cita

ADO.NET. No obstante parece que cuando los
volúmenes de datos son considerables ADO da mejor rendimiento.

Hay cosas mucho más importantes que diferencias marginales en el
rendimiento.


Saludos
Alfredo

Mostrar la cita

Hay cosas mucho más importantes que diferencias marginales en el
rendimiento.

Cuando se manejan volumens altos de datos, la prioridad es el rendimiento.
En fin nadie impide usar una combinación. Me interesa ADO.NET para
productividad en la Web...

Salu2,
<Harvey Triana />




"Alfredo Novoa" escribió en el mensaje
news:
Mostrar la cita

Hola Harvey,

On Wed, 18 Apr 2007 10:04:09 -0500, "Harvey Triana"
wrote:

Mostrar la cita

Por supuesto no hay discusión de que ADO.NET es superior a ADO.

Yo no tengo nada claro que la productividad de ADO.NET sea superior a
la de ADO. Y tengo bastante claro que es inferior a la de Visual Fox,
PowerBuilder y Delphi.

Mostrar la cita

Tecnología
nueva es tecnología nueva.

Hay montones de ejemplos de tecnología nueva que es inferior a
tecnología vieja.

Mostrar la cita

ADO.NET. No obstante parece que cuando los
volúmenes de datos son considerables ADO da mejor rendimiento.

Hay cosas mucho más importantes que diferencias marginales en el
rendimiento.


Saludos
Alfredo

On Wed, 18 Apr 2007 11:51:55 -0500, "Harvey Triana"
wrote:

Mostrar la cita

Mostrar la cita

Hay cosas mucho más importantes que diferencias marginales en el
rendimiento.

Cuando se manejan volumens altos de datos, la prioridad es el rendimiento.

¿Hablas de terabytes?

Porque sino ni de broma.


Saludos