DataSet vs clases propias

Alfredo:

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.

Pero es que eso no es cierto. No se a qué te refieres. Hay un modo
desconectado, dataSet y un modo conectado DataReader y comandos.

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.

¿Te refieres es a que no existe un modo conectado que enlace datos e
interface?. Si realmente fuese conectado, implicaría el uso de cursores. En
el mejor de los casos habría una solución desconectada que realice de forma
transparente la conexión cuando sea necesaria. Esa si podría ser una pequeña
mejora en ado.net, y de hecho, que creo que aparecerá en la próxima versión.
En cualquier caso, la diferencia con el modelo actual en ado.net sería muy
pequeña.

Que conste que en realidad una base de datos distribuida debe comportarse a
efectos de rendimiento de forma similar a un cursor, puesto que muchos
procesos deben ser similares pero todavía más costosos. No creo que pueda
existir nada eficiente que solucione los problemas de concurrencia en una
base de datos distribuida. Dudo por lo tanto que sea ninguna solución.

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.

Pero todos estos problemas, todavía tienen que ser mucho mayores en un
sistema distribuido. Al utilizar datasets, el programador, puede utilizar su
conocimiento de la naturaleza de la aplicación para optimizar estos
procesos. El sistema distribuido, tiene que deducir muchas cosas que el
progra,ador conoce, y todo ello en tiempo real. Sinceramente no veo
soluciones eficientes para esta cuestión, y al parecer ningún implementador
real (no teórico) ha podido lograrlo.

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?

Yo diría que imaginas como podría ser mejor, pero llevarlo a la práctica
suele ser mucho más costoso. Es como lo que decías de que las conexiones no
consuman recursos. ¿Optimizarlo tanto como lo puede hacer un ser humano?.
Hoy por hoy hay una diferencia casi infinita entre la inteligencia, grado de
conocimiento del problema, etc... del ser humano y el de un programa
informático. Estoy convencido de que alguna día dejará de ser así, pero de
momento es lo que hay.

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.

Realmente yo soy también de los que no conoce esos avances. Como he dicho,
no conozco ninguna implementación práctica comparable en eficiencia con los
SGBD convencionales. Aunque es posible que sea por mi propia ignorancia.

Por otro lado, hay muchos detalles de la filosofía de .net por los que no
creo que una base de datos distribuida fuese una solución interesante. ¿Qué
protocolos gestionarían el sistema?. Para poderse utilizar en internet,
deberían ser protocolos estandar que no diesen problemas con cortafuegos ni
con los routers existentes. ¿Propones comunicar el sistema mediante http?.
Por otro lado, el cliente debe ser lo más ligero que sea posible. Estoy
convencido de la importancia que tendrán en un futuro los dispositivos
móviles. Lo siento, pero creo que un motor distribuido no seria la solución
a los problemas actuales reales.

Juan Carlos Badiola
MVP - C#

Eso si, evidentemente puede haber soluciones distribuidas concretas que si
sean realmente eficaces. Siempre y cuando no sean genéricas. Por ejemplo
cuando podamos simplificar ciertos aspectos relativos a concurrencia. Por
ejemplo, evidentemente se puede crear una base de datos LDAP sobre un grupo
de máquinas. Sería un ejemplo de base de datos distribuida muy eficiente en
sus implementaciones reales, pero para eso hay que garantizar ciertas
premisas. No sirve como solución genérica.

Juan Carlos Badiola
MVP - C#

On Wed, 22 Dec 2004 20:51:22 +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.

No, se traen para mostrarselos a los usuarios.

Si se traen para que el programa los manipule automáticamente sin
intervención de los usuarios y mediante código procedimental, entonces
mala cosa.

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.

Aquí estás utilizando el término "manejar los datos" con un sentido
diferente al que yo estoy usando. Cuando hablo de manejar los datos me
refiero al tratamiento automático de la información (computación) y no
a las acciones de los usuarios de la aplicación.

Sería más preciso decir que los usuarios afirman y niegan hechos.

Dato viene del latín datum, que significa dado (del verbo dar). Dato
significa hecho dado.

Es decir los usuarios dan hechos y el sistema informático es quien
maneja (procesa) estos hechos dados y asegura que el conjunto de
hechos (base de datos) sea consistente, es decir que no existan
contradicciones.

La teoría moderna de bases de datos es una aplicación muy directa de
la lógica matemática. Si se enfoca el problema desde el punto de vista
de las matemáticas las cosas se ven bastante más claras.

Entiendo la diferencia entre los conceptos, por eso no veo en que momento
el DataSet rompe ese encapsulamiento.

El DataSet no lo rompe, lo habías roto tú cuando escribiste esto:

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

Puedo parecer muy quisquilloso, pero es que es una confusión muy
frecuente e importante. A veces yo también me confundo O:), pero
intento no hacerlo.

El SGBD y la base de datos son dos componentes perfectamente separados
y fundamentales. No deben de tratarse como si fuesen una unidad. Y
esto no es un problema lingüistico, sino que suele tener consecuencias
prácticas importantes. Mucha gente desconoce o se olvida del verdadero
propósito de un SGBD y lo infrautiliza como si fuese un sistema de
ficheros.

Este error es muy frecuente en los artículos de la MSDN.

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 :)

No estés tan seguro :)

Hay un fenómeno muy frecuente y poco conocido en el mundo de la
informática que podría llamarse "el fenómeno de la mismidad", y que
consiste en que mucha gente piensa que dos cosas son distintas cuando
en realidad son iguales. Es decir que no nos damos cuenta de que dos
palabras son sinónimas y de que decimos lo mismo de formas distintas.
Te podría dar montones de ejemplos del mundo de la OO.

Seguro que en el fondo no estamos tan en desacuerdo.

La capa de datos, que incluye los datos "y los procesos para acceder a
ellos",

Mala mezcla. Estás mezclando los datos particulares de una empresa en
un determinado momento con detalles de implementación.

Los datos no se deberían mezclar con ninguna otra cosa.

las reglas de negocio, que pueden estar "distribuidas" entre el motor de la
base
de datos (procedimientos, triggers, etc) y aplicaciones (o bibliotecas)
externas

El término correcto es SGBD, no motor de base de datos.

Pero lo que dices es bastante cierto. Las reglas de negocio siempre
las debe de garantizar el SGBD, pero los SGBD deben de ser
extensibles, y estas extensiones: procedimientos, procedimientos
disparados (triggers) y bibliotecas externas también son aplicaciones.

Un SGBD es un conjunto de aplicaciones (sistema) destinadas la gestión
de bases de datos, y este conjunto se debe de poder ampliar con nuevas
aplicaciones, ya sea de forma interna o externa (una dll por ejemplo).

Podríamos desarrollar una biblioteca para algún proceso que fuese muy
dificil de implementar en SQL, como por ejemplo temas de investigación
operativa y hacer que el SGBD utilizase ese módulo.

En donde no se deben de asegurar las reglas de negocio es en las
aplicaciones destinadas a presentar información e interactuar con los
usuarios. Es decir, en las aplicaciones que no pertenecen al SGBD.

Por cierto, el SGBD tiene que ofrecer una interfaz de comunicación a
las aplicaciones de usuario (ODBC y similares). Supongo que esto es a
lo que tú llamas los procesos para acceder a los datos.

y la capa de presentación que se ocupa solamente de la presentación.

Y el lugar ideal para esta capa son las aplicaciones que manejan los
usuarios. Las aplicaciones de interfaz de usuario solo se deberían
ocupar de la presentación y la comunicació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.

Tienes toda la razón, pero eso no es nada bueno. Es algo que
tendríamos que intentar evitar, por que si cambiamos el Varchar(100)
por un Varchar(500) el TexBox solo nos va a dejar introducir 100
caracteres. Cada vez que cambiasemos la longitud de un Varchar
tendríamos que ponernos a revisar uno por uno todos los TexBox de
todas las aplicaciones.

Esto se solucionaría con una conexión todavía más fuerte entre la
interfaz de usuario y el SGBD. Todo lo contrario de los DataSets
tipados, que cuando hay cambios en el diseño de la base de datos se
pueden quedar completamente descoordinados.

Es decir que al conectar un TextBox a un atributo de una tabla de tipo
Varchar(100) la longitud máxima se asignase automáticamente a 100.
No es tan complicado, hay sistemas que hacen cosas parecidas.

También estoy de acuerdo en que ese tipo de limitaciones en el número
de caracteres suele ser por cuestiones de implementación y no de
teoría. Deberían construirse SGBD en los que no hiciese falta
introducir esas limitaciones artificiales. Y esto también se lo he
oido decir a desarrolladores del SGBD de Oracle.

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?

Vas en contra del principio que dice que las bases de datos deben de
ser gestionadas por el SGBD y no por las aplicaciones de presentación.

La manera correcta de hacer esto sería que la aplicación enviase al
SGBD una orden en SQL para que el SGBD efectuase ese proceso.

En caso de que fuese necesario podrías ampliar el SGBD con una
aplicación que hiciese ese proceso, pero esto debería de ser un último
recurso.

Con SQL Server 2005 va a ser muy fácil añadir nuevas aplicaciones al
SGBD con .dll desarrolladas en cualquier lenguaje .NET. Esto va a ser
muy útil por ejemplo para crear nuevos tipos de datos.

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.

El diseño mejor es el diseño que te deja elegir ;-)

Por ejemplo con Delphi puedes elegir el diseño que prefieras en cada
momento. Con ADO.NET no. De lo que más me quejo es de esto, de no
poder elegir.

Lo normal en la mayoría de los casos es elegir el modo automático. Si
el modo automático lo hace perfectamente para que vamos a hacerlo a
mano.

Como decias
antes, el CommandBuilder lo hace automáticamente

Creo que te equivocas, el CommandBuilder lo que hace automáticamente
es generar las SQL de actualización. Sigue haciendo falta enviar las
actualizaciones a mano, y además el CommandBuilder solo funciona bien
en casos muy sencillos.

, 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.

A mi me pasa todo lo contrario. Los ordenadores están para automatizar
las cosas. Es absurdo que queramos automatizar el trabajo de los demás
y no querramos hacer lo mismo con el nuestro.

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?

Pues seguramente tengas razón. Yo lo que conozco bien es Delphi, el
primer Visual Studio con el que he trabajado en serio es el Visual
Studio 2003.

Con Delphi si intentas actualizar un DataSet conectado, la petición de
actualización se transmite inmediatamente al SGBD, y si el SGBD la
rechaza, la actualización se cancela automáticamente mostrando al
usuario el mensaje de error correspondiente. Todo esto con 0 lineas de
código.

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 :)

Pues yo noto claramente que tengo que trabajar mucho más para
conseguir lo mismo que hacía antes trabajando conectado y las
aplicaciones son mucho más frágiles y difíciles de mantener.

¿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.

Compararlo con un SGBD ;-)

Pues no estoy nada de acuerdo, a mi me parece perfectamente apropiado
comparar usar SGBD con usar el sistema de ficheros directamente.

La primera opción gana siempre que queramos hacer algo mínimamente
complicado, igual que en el caso de comparar un SGBD distribuido con
los DataSets de ADO.NET.

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.

Pues a mi me salta una excepción que me tira abajo el programa si no
la atrapo :)

La
cuestión
es si hay una diferencia que haga el DataSet menos apropiado que un
Recordset

Pues para mi la cuestión es si podría haberse hecho algo mucho mejor
que los DataSets de ADO.NET, y estoy convencido de que si.

para acceder a una base de datos o que rompe la filosofia del acceso a
datos, para
decir que es un diseño malo.

Bueno o malo siempre es relativo. Si algo se puede hacer mucho mejor
es que no es muy bueno :)

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.

¿En que autores te basas para decir eso?

Los libros de los autores más prestigiosos del mundo de las bases de
datos dicen lo que yo he escrito, vamos que lo he sacado de allí :)

Si quieres te doy referencias.

Manejar y gestionar es lo mismo, y la G de SGBD dice bien claro para
lo que son.

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.

Es que no pretendía ser una traducción. Además manejan muy mal la
terminología, por que entre otras cosas, a lo que llaman aplicaciones
distribuidas en realidad son sistema distribuidos.

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 ;)

Es que mira lo que has escrito:

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

Aquí la palabra "uso" no tiene mucho sentido.

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.

Estás sacando mi frase de contexto. De lo que estabamos hablando aquí
es de por que a veces la teoría no funciona en la práctica, y te había
dicho que es por defectos en la implementación de las herramientas.

Por ejemplo en teoría un join no tendría por que ser más lento que
cualquier otra operación, pero desgraciadamente con la mayoría de las
implementaciones existentes si lo es.

ADO.NET
es una biblioteca para el acceso a datos y no un motor de bases de datos.
Equipararlos es comparar churras con merinas.

Yo no pretendo equipararlos, sino todo lo contrario. Lo que digo es
que los datasets de ADO.NET son una solución muy pobre comparada con
otras alternativas que existen para solucionar los mismos problemas.

Es como decir que no se puede comparar un rifle con un tirachinas.
Pues no, no se puede, pero si me ataca un león yo prefiero tener un
rifle :)


Saludos
Alfredo

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 realidad esto se basa en el empléo de cursores, y cursores auténticos, no
como DataReader. Habiamos quedado en que no se deben utilizar cursores. ¿No
es cierto?.

Evidentemente es más fácil programar con cursores. Pero que sea más sencillo
no lo convierte en mejor.

Juan Carlos Badiola
MVP - C#

Me supongo que anonymous11 se refiere a hacer clases entidades que tienen
comportamientos.

"anonymous11" wrote:

he estado investigando ciertos temas de arquitectura y me
dicen que los dataset no tienen un diseño correcto en
temas de arquitectura y que mejor es utilizar clases
propias.
que me pueden decir...