DataSet vs clases propias

On Mon, 20 Dec 2004 09:05:25 +0100, "SqlRanger"
wrote:

Un dataset no pretende ser una pequeña base de datos en memoria

Lo realmente importante no es lo que pretenda, sino lo que es. Un
objeto dataset es una base de datos en memoria que coge algunas ideas
del Modelo Relacional. Pero es una base de datos con unas
posibilidades de manipulación realmente pobres.

Un dataset es un contenedor para un conjunto de objetos datatable, y
es evidente que un conjunto de tablas es una base de datos.

Por cierto, coger unas pocas ideas de aqui y de allá como en el caso
de ADO.NET suele dar resultados muy malos. Al Modelo Relacional no le
sobra ni una coma, y si cogemos unas cosas y dejamos otras, el
resultado va a ser siempre una chapuza como DBase.

No creo que lo datasets tengan que implementar ni lenguaje de consultas ni
otras reglas de integridad ya que éstas ya están disponibles en la base de
datos que es donde deben estar.

Están disponibles en el SGBD. Nunca hay que confundir una base de
datos (un conjunto de datos), con un SGBD (Sistema de Gestión de Bases
de Batos).

El problema de llamar base de datos a todo no está en el mal uso del
lenguaje sino en los errores prácticos que provoca la confusión de los
dos conceptos. Estos errores son mucho más frecuentes de lo que la
gente se imagina.

Por otra parte cuando estamos "desconectados" no están disponibles ni
el lenguaje de consultas ni las reglas de integridad que no sean
claves primarias y foraneas. Cuando estamos desconectados estamos en
pelotas.

Tenemos dos opciones: manipular los datasets de forma rudimentaria
(Find, Filter, Add, etc.) con código procedimental y comprobar las
reglas a pelo o conectarnos continuamente al SGBD para cada operación.

La primera solución es tremendamente engorrosa e ineficaz, y con la
segunda estamos renunciando a la arquitectura desconectada y no deja
de ser engorrosa comparada con los viejos Recordsets con los que
estabamos conectados todo el rato sin tener que hacer nada.

Para tener una "arquitectura desconectada" decente (el término
apropiado sería arquitectura distribuida) se necesitaría mucho más que
los simplistas datasets. Con todas estas deficiencias la "arquitectura
desconectada" es más un estorbo que un beneficio. Mucha gente echa de
menos los viejos Recordsets

¿Qué se necesitaría según tú?

Se necesitaría implementar toda la funcionalidad de un SGBD
distribuido. Es decir los datatables tendrían que estar siempre
conectados a un SGBD local que garantizase las reglas de integridad
(importandolas automáticamente a poder ser), que tuviese un lenguaje
de consultas relacional, y que el SGBD local se conectase a el SGBD
central (u otros SGBD distribuidos) cada vez que se necesitase
sincronizar la base de datos. Todo de la forma más automatizada
posible.

El SGBD local podría estar implementado en una DLL.

De esta forma tendríamos todas las ventajas de los dos mundos: el
conectado y el desconectado.

Todo esto está más que estudiado y existe mucha literatura sobre
sistemas de bases de datos distribuidos, pero parece que la gente del
equipo de ADO.NET no está al tanto.

Comparado con lo que podría haberse hecho, los datasets son una
auténtica ñapa.

Lo recordsets desconectados no proporcionan
mayor funcionalidad ni flexibilidad que la combinación de datasets y
dataadapters.

Yo me refería a los recordsets conectados, que puede que tengan
algunos problemas de rendimiento, pero son infinitamente más
productivos y más sencillos de utilizar.

Cuando algo que era fácil de hacer se vuelve engorroso y complicado, a
eso se le llama retroceso.


Saludos
Alfredo

Alfredo. Creo que no has comprendido el sentido de la pregunta de
anonymous11. Él no estaba pretendiendo comparar los datasets con el modelo
relacional. Muy por el contrario, lo estaba comparando con colecciones
personalizadas. Todas las limitaciones presentes en dataset frente a un
nmotro relacional, serían aún mayores en una colección. No conviene mezclar
churras con merinas. No creo que ayude al que está realizando la pregunta.

Por otro lado, estoy completamente de acuerdo con SqlRanger. DataSet no
pretende sustituir la funcionalidad del modelo relacional. En absoluto.
Sería un tanto absurdo duplicar la funcionalidad de un motor relacional
dentro de tu propia aplicación, creo yo. Para eso, sigue existiendo el
modelo relacional subyacente, y en último término el modo conectado. DataSet
tan solo pretende ofrecer una buena alternativa a otras formas de modelo
desconectado como pueden ser las colecciones especializadas.

Por cierto, los recordsets desconectados ofrecen menos capacidad relacional
todavía que dataset, en ese sentido, no comprendo a que te refieres con que
mucha gente echa de menos los viejos recordsets refiriendote a esta
cuestión.

Juan Carlos Badiola
MVP - C#

Sigo pensando que no has cogio la idea de la filosofía de ado.net.

Para empezar hay que conocer una vieja regla recomendada para la gestión de
datos, siempre que se pretenda crear aplicaciones medianamente escalables.
No se deben utilizar cursores. En ado, no se deben utilizar cursores. Lo
único que ha cambiado en ado.net, es que esa recomendación que en general
todo buen programador cumplía, es ahora una exigencia. En ado.net no existen
los cursores. Puedo asegurarte que toda la documentación de que dispongo
sobre este tema, mucho antes de la aparición de ado.net, insiste en que no
deben utilizarse cursores.

Por otro lado, en ado.net hay dos modos: desconectado y conectado. El modo
conectado, permite las mismas cosas que un recordset conectado, del unico
tipo recomendado. De solo avance y solo escritura para consultas. Para
actualizaciones se debven utilizar comandos. Esta es exacatamente la
filosofía del modo conectado en ado.net. Por otro lado, dataset permite más
o menos las mismas cosas que un recordset desconectado, con la diferencia de
que sigue un modelo relacional, mientras que recordset sigue un modelo
jerárquico.

Juan Carlos Badiola
MVP - C#

On Mon, 20 Dec 2004 16:54:42 +0100, "Tristan"
wrote:

Para empezar hay que conocer una vieja regla recomendada para la gestión de
datos, siempre que se pretenda crear aplicaciones medianamente escalables.
No se deben utilizar cursores.

Yo aun diría más. Los cursores nunca deberían de estar a la vista de
los programadores de aplicaciones. Yo no he hablado de cursores para
nada.

En ado, no se deben utilizar cursores. Lo
único que ha cambiado en ado.net, es que esa recomendación que en general
todo buen programador cumplía, es ahora una exigencia.

Pero se ha hecho de una forma totalmente chapucera.

Por otro lado, en ado.net hay dos modos: desconectado y conectado. El modo
conectado, permite las mismas cosas que un recordset conectado, del unico
tipo recomendado.

¿Y como se conecta un dataset sin escribir código?

Con el DataSnap de Delphi si hay dos modos, el conectado y
desconectado, pero con ADO.NET es la primera vez que lo leo.

De todas formas el modo desconectado es un error garrafal y un
retroceso a la edad de piedra. La solución correcta y evidente es
trabajar siempre en modo conectado utilizando un SGBD distribuido, que
para eso están.

filosofía del modo conectado en ado.net. Por otro lado, dataset permite más
o menos las mismas cosas que un recordset desconectado

Los recordsets desconectados tampoco deberían utilizarse más que en
casos MUY sencillos y especiales (una lista de teléfonos y poco más).

, con la diferencia de
que sigue un modelo relacional, mientras que recordset sigue un modelo
jerárquico.

No puede decirse que sigan un modelo relacional (Modelo Relacional
solo hay uno), sino que copian algunas ideas del Modelo Relacional
como hacía DBase. Vuelvo a decir que andar picando ideas de un lado y
de otro sin saber muy bien lo que se hace suele dar resultados muy
malos.


Saludos

On Mon, 20 Dec 2004 16:43:06 +0100, "Tristan"
wrote:

Alfredo. Creo que no has comprendido el sentido de la pregunta de
anonymous11.

Su pregunta podía tener dos sentidos y le he dado dos respuestas, una
para cada sentido.

El mensaje que estás contestando no iba dirigido a anonymous11, sino a
SqlRanger.

Él no estaba pretendiendo comparar los datasets con el modelo
relacional. Muy por el contrario, lo estaba comparando con colecciones
personalizadas. Todas las limitaciones presentes en dataset frente a un
nmotro relacional, serían aún mayores en una colección.

Estoy totalmente de acuedo, fíjate en lo que le he respondido a
anonymous11:

Pero si te refieres a crear una clase distinta para cada tabla como
por ejemplo: Cliente, Articulo y cosas así, entonces olvídate por que
eso si que es una barbaridad mucho peor que los errores de diseño de
los dataset.

Es decir que le he dicho lo mismo que me estás diciendo ahora.

Por otro lado, estoy completamente de acuerdo con SqlRanger. DataSet no
pretende sustituir la funcionalidad del modelo relacional.

Pero es una funcionalidad imprescindible, es lo mínimo que necesitamos
para trabajar cómoda y eficazmente. Si se quiere trabajar desconectado
se tiene que poder hacer de forma transparente, es decir sin que el
programador de aplicaciones pierda ninguna funcionalidad.

Una aplicación bien hecha no debería requerir ninguna modificación
para trabajar en modo conectado o desconectado, y para eso toda la
funcionalidad de un "motor relacional" tiene que estar disponible
cuando estemos desconectados.

En absoluto.
Sería un tanto absurdo duplicar la funcionalidad de un motor relacional
dentro de tu propia aplicación, creo yo.

No tendría que ser dentro de la propia aplicación sino que podríamos
trabajar con datasets conectados a un SGBD distribuido que incluyese
un "motor" (módulo) local, que es la solución evidente.

El problema es que necesitaríamos un SGBD distribuido y hay pocos
disponibles en el mercado y podríamos tener problemas si cambiamos de
SGBD.

Una solución más flexible es crear un "middleware" relacional. Es
decir un "motor" relacional que se ejecutaría localmente y se
conectaría a un SGBD remoto de cualquier fabricante cuando hiciese
falta. Algo del estilo de DataJoiner de IBM. Este "middleware" debería
tener una interfaz relacional, y trabajaríamos siempre conectados a
él.

Esta es una solución infinitamente superior al modo desconectado de
ADO.NET, y no creo que esto sea algo que MS no se pueda permitir.

Este motor debería de estar incluido en el .NET Framework.

En resumen: el obtener nueva funcionalidad no debería hacerse a costa
de perder funcionalidad que ya teníamos, y menos si se trata de algo
tan útil y potente como el Modelo Relacional.

Para eso, sigue existiendo el
modelo relacional subyacente, y en último término el modo conectado. DataSet
tan solo pretende ofrecer una buena alternativa a otras formas de modelo
desconectado como pueden ser las colecciones especializadas.

Estamos de acuerdo, pero el modo conectado de ADO.NET es más incómodo
que el modo conectado tradicional de por ejemplo Delphi, y el modo
desconectado es una alternativa pésima a un "middleware" relacional o
a un SGBD distribuido, ambos en modo conectado.

Por cierto, los recordsets desconectados ofrecen menos capacidad relacional
todavía que dataset, en ese sentido, no comprendo a que te refieres con que
mucha gente echa de menos los viejos recordsets refiriendote a esta
cuestión.

Me refiero a poder desarrollar una aplicación en modo conectado en muy
poco tiempo sin apenas escribir código. Yo provengo de Delphi y echo
eso mucho de menos.

El modo conectado de Delphi tiene bastantes limitaciones pero hay
montones de cosas (las más habituales), que se pueden hacer con muy
poco esfuerzo.


Saludos
Alfredo