DataSet vs clases propias

On Wed, 22 Dec 2004 10:36:21 +0100, "Juan Carlos Paramá"
wrote:

A riesgo de meterme donde no me llaman no entiendo muy bien este argumento.

Cualquier opinión es bienvenida.

El DataSet no pretende sustituir a una base de datos relacional y su modo
"desconectado"
no significa que pueda tener mis datos en memoria y consultarlos como si la
base de datos
no existiese.

¿Que significa entonces?

Por que desde luego con un dataset se puede hacer eso.

Y segundo, creo que ha quedado claro que no hay un modo conectado y
otro desconectado, los datasets están siempre desconectados y punto.

Si hubiese un modo realmente conectado entonces no habría problema. El
que quisiera lo podría usar y listo.

El problema está ahí: si quieres trabajar desconectado entonces lo que
ofrecen los datasets es demasiado pobre, y si quieres trabajar
conectado no puedes y tienes que simularlo de forma manual.

Es más, es fundamental que la base de datos exista. El
desconectado simplemente
significa que yo obtengo los datos "y me desconecto", no que trabaje
totalmente desconectado
de la base de datos.

O estás conectado o estás desconectado, no hay término medio.

Si modificas algún dato del dataset, el SGBD no puede asegurar la
integridad de los datos por que estás modificando una base de datos
local desconectada.

La única forma razonable de asegurar la integridad es enviar cada
modificación manualmente al SGBD y ver si la acepta o capturar y
tratar la exepción correspondiente en el caso de que no la acepte. Y
para eso tenemos que crear a mano una consulta de actualización en
SQL, otra de inserción y otra de borrado además de la de selección. Y
además hay que crear los objetos parámetro correspondientes y escribir
el código para la gestión de errores. Y todo esto para no obtener
ninguna ventaja con respecto a trabajar conectado.

Si tienes que hacer esto con varios cientos de tablas (una aplicación
mediana), es una auténtica pesadilla y el resultado es un monstruo. Es
un trabajo lento, monotono, tedioso y frustrante. Nunca hay que
olvidar que el tiempo es dinero.

Alguno dirá que se puede usar un CommandBuilder, pero en la práctica
es una herramienta muy limitada y la mayoría de los libros recomiendan
no usarlo. Pero con CommandBuilder y todo, el proceso sigue siendo
mucho más engorroso de lo necesario.

En el libro: Microsoft ADO.NET Core Reference, vienen algunos ejemplos
de aplicación absolutamente triviales ¡Pero que necesitan muchos
cientos de lineas de código!

(aunque supongo que se podrá modelar toda una "base de
datos" en memoria
en un DataSet no tengo dudas de que esa no es la intención de Microsoft).

Claro que se puede, pero las posibilidades de manipulación y de
garantizar la integridad de un DataSet son pobrísimas.

El objetivo del DataSet es que sea la maquina cliente la que cargue con el
uso de los recursos y
no el servidor. Puede que la solución aportada no guste, pero lo consigue de
forma bastante
aceptable.

¿Bastante aceptable comparada con que?

Comparada con lo que yo explicaba es una solución pobrísima. Y si yo
se como hacerlo mucho mejor ¿Por que no saben ellos?

Vamos, que no veo la diferencia entre hacer una select, guardar los datos en
un recordset y seguir
ocupando el servidor con información sobre el cursor y la conexión o hacer
la select, guardar los
datos en un dataset y liberar todos los recursos en el servidor, excepto en
la transferencia en el
uso de recursos del servidor al cliente.

El problema no es ese, el problema es que cuando modificamos los datos
de un recordset, esto se hace fuera del control del SGBD. Esto puede
traer muchos problemas y nos obliga a controlar un montón de cosas de
forma manual.

Ya he explicado como se pueden conseguir las dos cosas: liberar
recursos del servidor, pero sin perder el control del SGBD.

Lo que hacen los DataSets es como quemar los muebles para calentarnos.
Si, nos calentamos, pero hay otras formas de calentarse y no tener que
dormir en el suelo.

Evidentemente tienes derecho a creer que un DataSet no debe hacer eso, sino
otra cosa, Microsoft
no lo cree así, y yo tampoco.

Ahí está el problema. Mucho me temo que ni el equipo de ADO.NET ni tú,
estais muy al corriente de los avances en teoría de bases de datos
distribuidas de las últimas décadas.


Saludos
Alfredo

Hola,

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 22 Dec 2004 10:36:21 +0100, "Juan Carlos Paramá"
wrote:




O estás conectado o estás desconectado, no hay término medio.

Te concedo que en un sentido estricto del termino tienes razón, pero creo
que hay una diferencia practica fundamental. Intento aclararlo en el
siguiente
parrafo.

Si modificas algún dato del dataset, el SGBD no puede asegurar la
integridad de los datos por que estás modificando una base de datos
local desconectada.

Y si leo un registro con un select y modifico uno de sus datos en mis
variables
en el programa tampoco puedo asegurar la integridad, y nadie dice que las
variables no son un buen metodo de manejar registros en memoria. Una cosa
es el SGBD (con toda su teoria detras) y otra mi programa, que se encarga de
manejar esos datos y de actualizar la base de datos *para que esta* se
encargue
de la integridad. Un DataSet es una estructura para manejar *en mi programa*
los
datos de la base de datos, no para asegurar la integridad, para eso ya esta
el motor
de la base de datos. Y una variable en memoria no es conectada ni
desconectada,
es el programa (o el sistema) el que decide en que momento se establece la
conexión
y en el cual se cierra. Que más da si entre la select y el update la
conexión a la base
de datos esta abierta (conectado) o cerrada (desconectado) todo el sistema
sigue
dependiendo de la base de datos.

La única forma razonable de asegurar la integridad es enviar cada
modificación manualmente al SGBD y ver si la acepta o capturar y
tratar la exepción correspondiente en el caso de que no la acepte. Y
para eso tenemos que crear a mano una consulta de actualización en
SQL, otra de inserción y otra de borrado además de la de selección. Y
además hay que crear los objetos parámetro correspondientes y escribir
el código para la gestión de errores. Y todo esto para no obtener
ninguna ventaja con respecto a trabajar conectado.

Vale, parece que estamos de acuerdo en que un DataSet no es más que un
recordset con la diferencia de que los recursos son utilizados en el cliente
en
vez de en el servidor.

Queda a la voluntad de cada uno decidir si eso es una ventaja o no. A mi me
lo parece.

Si tienes que hacer esto con varios cientos de tablas (una aplicación
mediana), es una auténtica pesadilla y el resultado es un monstruo. Es
un trabajo lento, monotono, tedioso y frustrante. Nunca hay que
olvidar que el tiempo es dinero.

Es *casi exactamente* el mismo tiempo que hacer esa aplicación con sistemas
continuamente conectados (el recordset ADO por ejemplo). Hay que realizar
las mismas selects. Solo se tarda unos segundos más en crear el DataSet.

(aunque supongo que se podrá modelar toda una "base de
datos" en memoria
en un DataSet no tengo dudas de que esa no es la intención de Microsoft).

Claro que se puede, pero las posibilidades de manipulación y de
garantizar la integridad de un DataSet son pobrísimas.

Pero es que no es necesario manipularlos en la forma en que lo planteas. Que
posibilidades de manipulación tiene una variable de tipo String. Un DataSet
es
una estructura en memoria, nada más, ni nada menos claro.

El objetivo del DataSet es que sea la maquina cliente la que cargue con el
uso de los recursos y
no el servidor. Puede que la solución aportada no guste, pero lo consigue
de
forma bastante
aceptable.

¿Bastante aceptable comparada con que?

Comparada con lo que yo explicaba es una solución pobrísima. Y si yo
se como hacerlo mucho mejor ¿Por que no saben ellos?

No, porque la comparación no es apropiada. Un DataSet puede funcionar
tanto en un sistema distribuido como en una centralizado. Repito, el DataSet
es una estructura y no sabe nada de bases datos (centralizadas o
distribuidas)
y le da igual.

Comparado con RDO por ejemplo es una solución mucho más flexible.

El problema no es ese, el problema es que cuando modificamos los datos
de un recordset, esto se hace fuera del control del SGBD. Esto puede
traer muchos problemas y nos obliga a controlar un montón de cosas de
forma manual.

No más que cuando estas conectado. Si haces una inserción y falla tienes que
capturar el error. En el DataSet (a través del DataAdapter) igual, ¿cual es
la diferencia?

Ya he explicado como se pueden conseguir las dos cosas: liberar
recursos del servidor, pero sin perder el control del SGBD.

Cosa que en ningun momento se hace. Permiteme, sin pretender ofender, que
esta confundiendo un programa con el acceso a la base de datos. Para acceder
a la base de datos utilizo las sentencias SQL de toda la vida conforme a las
recomendaciones (incluyendo la ausencia de cursores) y para manejar los
datos
en mi programa en vez de guardarlos en variables String, arrays o Recordset
los
guardo en un DataSet. ¿Por que? Porque Microsoft ha creado todo una
estructura
que me facilita el data binding, la serialización XML, ... si utilizo
DataSets. Si solo
tuviese el DataSet (y nada más) no le vería ninguna ventaja con el recordset
(excepto
lo de los recursos del servidor). Como existe todo eso lo utilizo en vez de
crearme mi propio "DataSet".

Ahí está el problema. Mucho me temo que ni el equipo de ADO.NET ni tú,
estais muy al corriente de los avances en teoría de bases de datos
distribuidas de las últimas décadas.

En mi caso probablemente sea cierto, en la de Microsoft lo dudo, pero no
creo
que fuese su intención crear un sistema distribuido de bases de datos, si no
una
estructura para facilitar el uso de aplicaciones que utilizasen menos
recursos en
el servidor (además de intentar separar el acceso a los datos de las reglas
de negocio
y la presentación).

Y con la teoría hay que tener cuidado. La teoria SQL dice muchas cosas sobre
como obtener datos con joins, lefts joins, right joins y outers joins. La
practica dice
que muchos outer joins hay que replantearselos como selects más elaboradas o
nos
moriremos esperando, porque desgraciadamente la implementación de la teoria
no
siempre es fácil o posible.

Saludos,

Juan Carlos Paramá

On Wed, 22 Dec 2004 13:57:40 +0100, "Juan Carlos Paramá"
wrote:

Si modificas algún dato del dataset, el SGBD no puede asegurar la
integridad de los datos por que estás modificando una base de datos
local desconectada.

Y si leo un registro con un select y modifico uno de sus datos en mis
variables
en el programa tampoco puedo asegurar la integridad

Tampoco, por eso cuando se quiere modificar una base de datos hay que
decirle al SGBD que lo haga. De esta forma nos aseguramos de que la
base de datos va a estar siempre en un estado consistente.

, y nadie dice que las
variables no son un buen metodo de manejar registros en memoria.

Pero las bases de datos no se deben gestionar manejando registros en
la memoria de cada aplicación. Los SGBD se inventaron precisamente
para poder dejar de hacer esto que da tantos problemas.

Una cosa
es el SGBD (con toda su teoria detras) y otra mi programa, que se encarga de
manejar esos datos y de actualizar la base de datos *para que esta* se
encargue

Otra vez lo mismo. La teoría detrás del SGBD dice que no debe de ser
la aplicación la que se encargue de manejar la base de datos.

En tu frase detecto errores de concepto. Una cosa es la base de datos
(el conjunto de datos), y otra el SGBD: el sistema que se encarga de
gestionar (y esto incluye actualizar) la base de datos. SGBD significa
Sistema de Gestión de Bases de Datos.

Una aplicación jamás debe de acceder directamente a la base de datos
(a un fichero .mdf de SQL Server, por ejemplo), ni para actualizar ni
para nada.

El SGBD "encapsula" a la base de datos.

Cualquier sistema que use un SGBD tiene 3 capas:

-La base de datos (que puede estar almacenada en un fichero o, en un
disco, o de otras formas)
-El SGBD
-Las aplicaciones

A la primera se le suele llamar capa de datos, a la segunda capa de
reglas de negocio, y a la tercera capa de presentación.

de la integridad. Un DataSet es una estructura para manejar *en mi programa*
los
datos de la base de datos

Y esto es algo que no se debe de hacer. Es decir que los dataset están
diseñados para hacer algo que va en contra de los principios más
básicos de la gestión de bases de datos.

es el programa (o el sistema) el que decide en que momento se establece la
conexión
y en el cual se cierra.

De forma manual, cuando debería de ser algo automático.

Que más da si entre la select y el update la
conexión a la base
de datos esta abierta (conectado) o cerrada (desconectado) todo el sistema
sigue
dependiendo de la base de datos.

Efectivamente eso en teoría da igual. Pero a la hora de efectuar el
"update" deberíamos de estar conectados al SGBD, y eso es lo que los
dataset no hacen.

Por ejemplo si estás usando el modo conectado de Delphi y quieres
hacer un update (por ejemplo cambiar el contenido de una celda de un
"grid"), el dataset de Delphi traslada la petición al SGBD, el SGBD
decide si la petición se autoriza o no, en caso de que la petición se
autorice el SGBD actualiza la base de datos, en cualquier caso se
devuelve una respuesta a la aplicación y la aplicación presenta la
respuesta al usuario. Todo esto de forma totalmente automática.

En cambio el dataset de ADO.NET se traga lo que le echen sin rechistar
y los problemas llegan más tarde.

Vale, parece que estamos de acuerdo en que un DataSet no es más que un
recordset con la diferencia de que los recursos son utilizados en el cliente
en
vez de en el servidor.

No. Hay una diferencia fundamental: el recordset conectado es solo un
intermediario entre la interfaz de usuario y el SGBD, y el dataset es
una base de datos independiente.

El tema de los recursos es un detalle de implementación. Se podría
conseguir hacer exactamente lo mismo que un recordset conectado pero
utilizando recursos en el cliente en lugar de en el servidor.

A mi lo de liberar recursos del servidor pasando carga de trabajo a
los cada vez más potentes PC cliente me parece fenomenal. Lo que no me
parece bien es que se haga a costa de hacernos la vida mucho más
dificil a los programadores.

El mejor aprovechamiento de los recursos no debería hacerse a costa de
sacrificar el modelo, y menos un modelo que da tan buenos resultados.

Queda a la voluntad de cada uno decidir si eso es una ventaja o no. A mi me
lo parece.

Claro que es una ventaja, pero estamos pagando un precio muy alto e
innecesario.

Es *casi exactamente* el mismo tiempo que hacer esa aplicación con sistemas
continuamente conectados (el recordset ADO por ejemplo).

No estoy de acuerdo para nada. Sobre todo en sistemas multiusuario
complejos en los que hay que tener muy en cuenta los problemas de
concurrencia.

Claro que se puede, pero las posibilidades de manipulación y de
garantizar la integridad de un DataSet son pobrísimas.

Pero es que no es necesario manipularlos en la forma en que lo planteas. Que
posibilidades de manipulación tiene una variable de tipo String. Un DataSet
es
una estructura en memoria, nada más, ni nada menos claro.

No estoy comparando un DataSet con un string, sino con una base de
datos relacional. La diferencia es abismal.

Eso de que un DataSet no pretende sustituir a un SGBD relacional no me
vale por que un DataSet está diseñado para manejar datos, y esta es
exactamente la razón de ser de los SGBD. Los DataSets invaden
claramente las competencias de los SGBD. Esto es intrusismo
informático :)

¿Bastante aceptable comparada con que?

Comparada con lo que yo explicaba es una solución pobrísima. Y si yo
se como hacerlo mucho mejor ¿Por que no saben ellos?

No, porque la comparación no es apropiada.

¿Por qué no es apropiada, si las dos soluciones sirven para resolver
el mismo problema?

Comparado con RDO por ejemplo es una solución mucho más flexible.

Ya, no hay nada por malo que sea que no se pueda empeorar, pero eso no
es un gran consuelo.

El problema no es ese, el problema es que cuando modificamos los datos
de un recordset, esto se hace fuera del control del SGBD. Esto puede
traer muchos problemas y nos obliga a controlar un montón de cosas de
forma manual.

No más que cuando estas conectado.

Cuando estás conectado no hay que controlar nada. El SGBD le devuelve
al dataset conectado de Delphi un mensaje de error y el dataset lo
muestra automáticamente al usuario.

Si haces una inserción y falla tienes que
capturar el error. En el DataSet (a través del DataAdapter) igual, ¿cual es
la diferencia?

Es que eso no es estar conectado. Un dataset de ADO.NET nunca está
conectado.

Yo estoy comparando con sistemas en los que los controles de datos
están conectados al SGBD de verdad.

Ya he explicado como se pueden conseguir las dos cosas: liberar
recursos del servidor, pero sin perder el control del SGBD.

Cosa que en ningun momento se hace.

¿Como que no se hace si el dataset está desconectado?

Cae de cajón. Tu puedes modificar todo lo que quieras de un dataset,
que el SGBD no se va a enterar de nada. El SGBD ha perdido el control
y la exclusiva de la manipulación de los datos.

Permiteme, sin pretender ofender, que
esta confundiendo un programa con el acceso a la base de datos. Para acceder
a la base de datos utilizo las sentencias SQL de toda la vida

No, eso es un error de concepto muy grande. El único que accede a la
base de datos es el SGBD. Las aplicaciones no tienen acceso a la base
de datos. Las sentencias SQL son órdenes que se le dan al SGBD para
que este manipule la base de datos y nos devuelva una respuesta, que
puede ser de rechazo de la orden.

y para manejar los
datos
en mi programa en vez de guardarlos en variables String, arrays o Recordset
los
guardo en un DataSet.

Pero es que resulta que los SGBD se inventaron en los años 60
precisamente para dejar de manejar los datos en nuestros programas. La
aparición de los SGBD fue uno de los avances más importantes en la
historia del desarrollo de software.

Nuestras aplicaciones deben de servir para traducir las órdenes de los
usuarios a un lenguaje que entienda el SGBD (SQL), y presentar las
respuestas del SGBD de una forma que sea cómoda y manejable para los
usuarios.

Si no conoces este principio fundamental no me extraña que te hagas un
lio con el resto.

pero no
creo
que fuese su intención crear un sistema distribuido de bases de datos,

No, pero su intención era claramente la de crear unas herramientas que
sirviesen para crear sistemas distribuidos de bases de datos.

ADO.NET is a set of classes that expose data access services to the
.NET programmer. ADO.NET provides a rich set of components for
creating distributed, data-sharing applications.

http://msdn.microsoft.com/library/d...ADONET.asp

El problema es que son unas herramientas muy rudimentarias muy
alejadas del estado del arte.

si no
una
estructura para facilitar el uso de aplicaciones que utilizasen menos
recursos en
el servidor

Facilitar el desarrollo, no el uso. O sea, lo que acabo de decir.

(además de intentar separar el acceso a los datos de las reglas
de negocio y la presentación).

Aquí vuelvo a detectar los mismos fallos de concepto de antes.

El acceso a los datos se debe de realizar siempre a través del SGBD.
Por ejemplo si queremos acceder a la relación de empleados de la
empresa le debemos de hacer al SGBD la petición correspondiente en
lenguaje SQL. Y el SGBD nos dará los datos que pedimos solo en el caso
de que estemos autorizados a acceder a dicha información.

Con respecto a las las reglas de negocio, estas las debe de garantizar
también el SGBD.

Y la presentación es la responsabilidad fundamental de las
aplicaciones. Es decir que las aplicaciones constituyen la capa de
presentación y comunicación en un sistema de información bien
diseñado.

Las tres cosas ya están suficientemente separadas, pero lo que hacen
los datasets es todo lo contrario: mezclar las reglas de negocio con
la presentación, es decir que los datasets nos invitan a manipular
datos en la memoria de la aplicación y a asegurar algunas reglas de
negocio en la capa de presentación.

Y con la teoría hay que tener cuidado. La teoria SQL dice muchas cosas sobre
como obtener datos con joins, lefts joins, right joins y outers joins. La
practica dice
que muchos outer joins hay que replantearselos como selects más elaboradas o
nos
moriremos esperando, porque desgraciadamente la implementación de la teoria
no
siempre es fácil o posible.

Lo que en realidad nos dice la práctica es que los desarrolladores de
SGBD todavía no han sido capaces de llevar la teoría a la práctica de
forma aceptable, y nos obligan a buscar rodeos para evitar los
defectos de sus implementaciones.

El problema es que como nadie protesta pues nadie pone mucho interés
en solucionar estos problemas.

Es cierto que la implementación de un SGBD relacional es bastante
dificil, pero para nada es imposible.


Saludos

On Wed, 22 Dec 2004 13:57:40 +0100, "Juan Carlos Paramá"
wrote:

Ahí está el problema. Mucho me temo que ni el equipo de ADO.NET ni tú,
estais muy al corriente de los avances en teoría de bases de datos
distribuidas de las últimas décadas.

En mi caso probablemente sea cierto, en la de Microsoft lo dudo

Con respecto a esto, yo no he dicho Microsoft, sino el equipo de
ADO.NET, que debe de ser una parte pequeñísima de Microsoft.


Saludos

Hola,

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 22 Dec 2004 13:57:40 +0100, "Juan Carlos Paramá"
wrote:

Otra vez lo mismo. La teoría detrás del SGBD dice que no debe de ser
la aplicación la que se encargue de manejar la base de datos.

Veamos, ¿para que se traen los datos de un base de datos en cualquier
programa? Para manipularlos. Es decir, la teoria no puede decir que el
objetivo de un motor relacional no es que el usuario (sea una persona
con un terminal o un programa) no debe manejar los datos. Puede decir
que nunca debe obtenerlos de donde estan guardados directamente, pero
una vez que los tiene el usuario (persona o programa) puede manejarlos a
su antojo.

Una aplicación jamás debe de acceder directamente a la base de datos
(a un fichero .mdf de SQL Server, por ejemplo), ni para actualizar ni
para nada.

El SGBD "encapsula" a la base de datos.

Entiendo la diferencia entre los conceptos, por eso no veo en que momento
el DataSet rompe ese encapsulamiento. ¿Quien entrega los datos a la
aplicación?
El motor de la base de datos, el DataSet no accede fisicamente a nada para
obtener los datos, sino que a través de la interfaz definida por el motor
(SQL)
recupera los datos que la aplicación necesita. Pura teoria relacional y de
orientación
a objetos.

Cualquier sistema que use un SGBD tiene 3 capas:

-La base de datos (que puede estar almacenada en un fichero o, en un
disco, o de otras formas)
-El SGBD
-Las aplicaciones

A la primera se le suele llamar capa de datos, a la segunda capa de
reglas de negocio, y a la tercera capa de presentación.

Pues tenemos teorias distintas :)

La capa de datos, que incluye los datos "y los procesos para acceder a
ellos",
las reglas de negocio, que pueden estar "distribuidas" entre el motor de la
base
de datos (procedimientos, triggers, etc) y aplicaciones (o bibliotecas)
externas
y la capa de presentación que se ocupa solamente de la presentación. Como
toda teoria no se puede llevar al 100% a la practica. Ejemplo sencillo:
Varchar(100)
en base de datos, ¿Como garantizas que un usuario no introduzca más de 100
caracteres en un TextBox? Poniendo Longitud Maxima = 100. Ya has pasado
un dato de la base de datos (un dato además que solo existe por cuestiones
de
implementación, no de teoria) y lo has metido en la interfaz de usuario. Te
has
cargado la separación datos-interfaz.

Y esto es algo que no se debe de hacer. Es decir que los dataset están
diseñados para hacer algo que va en contra de los principios más
básicos de la gestión de bases de datos.

Un ejemplo. Hago una select que recupera 10 registros con 3 campos
cada uno. Los guardo en mi aplicación en tres arrays con 10 elementos
cada uno de ellos. Realizo las operaciones que creo convenientes y una
vez finalizadas esas operaciones guardo los resultados de nuevo en la
base de datos. ¿En que momento voy en contra de los principios básicos
de gestión de bases de datos?

Por ejemplo si estás usando el modo conectado de Delphi y quieres
hacer un update (por ejemplo cambiar el contenido de una celda de un
"grid"), el dataset de Delphi traslada la petición al SGBD, el SGBD
decide si la petición se autoriza o no, en caso de que la petición se
autorice el SGBD actualiza la base de datos, en cualquier caso se
devuelve una respuesta a la aplicación y la aplicación presenta la
respuesta al usuario. Todo esto de forma totalmente automática.

Vale, es decir, la única diferencia que el DataSet te obliga a decirle en
que momento quieres hacerlo. La verdad, que me dejen elegir si quiero
que la operación sea automática y sin posibilidad de decidir cuando
quiero la actualización o que hay que decirle al DataSet actualiza y hacerlo
cuando yo quiero no me cuesta decidir que diseño es mejor. Como decias
antes, el CommandBuilder lo hace automáticamente, pero a mi es que no me
gustan las sentencias generadas automáticamente, por eso me gusta tener la
posibilidad de elegir aun a costa de teclear una linea más.

No. Hay una diferencia fundamental: el recordset conectado es solo un
intermediario entre la interfaz de usuario y el SGBD, y el dataset es
una base de datos independiente.

Si modificas un recordset a través de programa estas modificando datos
sin actualizar la base de datos (no ocurre hasta que llames al metodo
Update).
¿Cual es la diferencia con el DataSet?

A mi lo de liberar recursos del servidor pasando carga de trabajo a
los cada vez más potentes PC cliente me parece fenomenal. Lo que no me
parece bien es que se haga a costa de hacernos la vida mucho más
dificil a los programadores.

Bueno, como programador, especificamente de aplicaciones de gestión contra
Sistemas de bases de datos relacionales, no considero que me lo hayan hecho
más dificil, sino más bien al contrario :)

Es *casi exactamente* el mismo tiempo que hacer esa aplicación con
sistemas
continuamente conectados (el recordset ADO por ejemplo).

No estoy de acuerdo para nada. Sobre todo en sistemas multiusuario
complejos en los que hay que tener muy en cuenta los problemas de
concurrencia.

Como ya los había que tener en modo conectado ¿no? A menos que
trabajes todo el tiempo con bloqueo pesimista siempre tienes que tener
en cuenta la concurrencia. Y ahora si es el entorno el que se encarga
de avisarte de un error de concurrencia no recurriendo a mecanismos
de row version o wheres kilometricos para comprobar diferencias.

Por cierto, ¿alguien sabe como implementa ADO.NET esta caracteristica?

Pero es que no es necesario manipularlos en la forma en que lo planteas.
Que
posibilidades de manipulación tiene una variable de tipo String. Un
DataSet
es
una estructura en memoria, nada más, ni nada menos claro.

No estoy comparando un DataSet con un string, sino con una base de
datos relacional. La diferencia es abismal.

Pero yo si lo estoy relacionando :)

Un DataSet es una estructura en memoria como lo es un String. Simplemente
almacena datos para que el programador los manipula. Solo que en vez de
guardar
una cadena como un String guarda todos los datos de un registro.

¿Por qué no es apropiada, si las dos soluciones sirven para resolver
el mismo problema?

Claro, y un fichero de texto plano tambien, y eso no significa que se pueda
comparar un fichero de texto con una base de datos.

Cuando estás conectado no hay que controlar nada. El SGBD le devuelve
al dataset conectado de Delphi un mensaje de error y el dataset lo
muestra automáticamente al usuario.

Y en ADO.NET *exactamente* igual. En el momento que le digas "Actualiza"
el sistema se encargará de devolverte todos los mensajes de error del SGBD.

Yo estoy comparando con sistemas en los que los controles de datos
están conectados al SGBD de verdad.

Evidentemente no es lo mismo, si fuese lo mismo no habría discusión. La
cuestión
es si hay una diferencia que haga el DataSet menos apropiado que un
Recordset
para acceder a una base de datos o que rompe la filosofia del acceso a
datos, para
decir que es un diseño malo.

Cae de cajón. Tu puedes modificar todo lo que quieras de un dataset,
que el SGBD no se va a enterar de nada. El SGBD ha perdido el control
y la exclusiva de la manipulación de los datos.

Repitiendome de nuevo. En mi aplicación puedo modificar todo lo que quiera
que para eso hace lo que yo decida. Eso no es perder el control de nada.
Siempre
es el SGBD el que va a decir si los datos son admisibles o no,
independientemente
de que sea un recordset o un DataSet.

No, eso es un error de concepto muy grande. El único que accede a la
base de datos es el SGBD. Las aplicaciones no tienen acceso a la base
de datos. Las sentencias SQL son órdenes que se le dan al SGBD para
que este manipule la base de datos y nos devuelva una respuesta, que
puede ser de rechazo de la orden.

Sigue siendo así en un DataSet.

Pero es que resulta que los SGBD se inventaron en los años 60
precisamente para dejar de manejar los datos en nuestros programas. La
aparición de los SGBD fue uno de los avances más importantes en la
historia del desarrollo de software.

No, el manejar los datos es responsabilidad del motor y de la aplicación
(capa de
negocio). Es la obtención de los datos lo que es competencia exclusiva del
SGBD.

Sigue siendo así con un DataSet.

No, pero su intención era claramente la de crear unas herramientas que
sirviesen para crear sistemas distribuidos de bases de datos.

ADO.NET is a set of classes that expose data access services to the
NET programmer. ADO.NET provides a rich set of components for
creating distributed, data-sharing applications.

http://msdn.microsoft.com/library/d...ADONET.asp

El problema es que son unas herramientas muy rudimentarias muy
alejadas del estado del arte.

Una traducción muy libre porque lo que dice esque "provee un gran conjunto
de componentes para crear aplicaciones de datos distribuidas", no es un
"sistemas
distribuidos de bases de datos", si no de aplicaciones distribuidas.

Facilitar el desarrollo, no el uso. O sea, lo que acabo de decir.

No entiendo esto muy bien. ADO.NET es para desarrolladores. Como yo lo veo
facilitar el
desarrollo *es* fácilitar el uso, ya que el único uso de ADO.NET es
desarrollar aplicaciones.
(perdón por el trabalenguas ;)

El acceso a los datos se debe de realizar siempre a través del SGBD.
Por ejemplo si queremos acceder a la relación de empleados de la
empresa le debemos de hacer al SGBD la petición correspondiente en
lenguaje SQL. Y el SGBD nos dará los datos que pedimos solo en el caso
de que estemos autorizados a acceder a dicha información.

Totalmente de acuerdo. En ADO.NET se hace eso especificamente.

Es cierto que la implementación de un SGBD relacional es bastante
dificil, pero para nada es imposible.

Razón por la cual esta discusión es un poco un dialogo de besugos. ADO.NET
es una biblioteca para el acceso a datos y no un motor de bases de datos.
Equipararlos es comparar churras con merinas.

Saludos,

Juan Carlos Paramá