DataSet vs clases propias

Para las
consultas en modo conectado tenemos DataReader.

Que no es más ni menos que una clase que encapsula a un

cursor

unidireccional de solo lectura. Un cursor y de los

peores. Pero la

discusión era acerca de los datasets.

En tu otro mensaje decías que no debían de usarse

cursores y estoy de

acuerdo.

En realidad DataReader no se considera un cursor. De
hecho, los "cursores" unidireccionales y de solo lectura
no se consideran cursores. El "cursor" fire-hose a menudo
es denominado también no-cursor. Evidentemente de alguna
forma el SGBD tiene que enviar datos a tu aplicación.
Pero precisamente el "cursor" de solo avance y solo
lectura es la más eficiente posible, el SGBD envía datos
a medida que los obtiene. Por esta razón no permite
retrocesos ni escrituras. Tan solo envía filas a medida
que las obtiene. No es un cursor. No requiere que el
servidor mantenga punteros entre la aplicación y las
filas de la consulta. No hay que confundir las cosas. No
puede existir ninguna forma más eficiente de comunicar el
SGBD y la aplicación.

Por otro lado no hay que olvidar que DataSet, o más bien
DataAdapter, realmente utiliza DataReader para comunicar
con el SGBD.

De todas
formas, no me gusta enlazar datos directamente con el
interface de usuario. ¿A eso te refieres?

Me refiero a enlazar el interfaz de usuario con el SGBD

de la forma

más sencilla posible.

Me imagino que no estarás en contra de que las cosas

sean sencillas de

hacer, siempre que no perdamos rendimiento ni

flexibilidad. Esto puede

conseguirse.

Pues no, no soy partidario de enlazar datos e interface.
Me parece una de esas cosas "sencillas" que van en
detrimento de la sencillez a medio y largo plazo, es
decir de la mantenibilidad. Soy más partidario de aislar
interface de usuario y formato físico de datos. No soy
partidario de ahorrar unas pocas lineas de código a
cambio de perder esa autonomía.

Para obtener un datareader tan solo hay que escribir un
ExecuteReader.

Pero no es más que un vulgar cursor. No se puede

conectar directamente

a un formulario Windows con campos de lectura y

escritura.

Evidentemente. Además de que no me parezca recomendable,
no se puede conectar un datareader por que precisamente
no es un cursor. No mantiene un enlace con el SGBD. De
todas formas, se pueden crear combinaciones de dataset y
DataReader muy interesantes. Yo lo he hecho en alguna
ocasión. La idea es utilizar DataSet/DataTable como
almacén temporal de la fila obtenida. Aunque no soy
partidario del enlace a datos, en algunos casos me ha
resultado útil trabajar así.

De todas formas, para los que no se sienten cómodos con
esta filosofía de trabajo, se sigue pudiendo utilizar
ADO, y sus tradicionales cursores de servidor. Yo no lo
recomendaría, pero ahí está.

¿Como puede hacerse? ¿Tienes alguna referencia?

Me podría ser bastante útil mientras no acabe de

implementar un

sustituto para los datasets.


Saludos
Alfredo
.

Bueno, no creo que sea necesaria ninguna documentación
especial. Tan solo necesitas añadir una referencia a la
librería de ADO y utilizar las clases y métodos ADO
tradicionales.

trabajar de forma desconectada. Ya sea para minimizar

las

conexiones abiertas

Eso se soluciona mejor con un "middleware". Pero ¿Por

que querríamos

minimizar las conexiones abiertas?

¿Para ahorrarnos dinero en las licencias?

Creo que en algunos casos hacer esto puede considerarse

como un

fraude.

Si es por motivos de rendimiento o aprovechamiento de

recursos

entonces es que el SGBD no gestiona muy bien las

conexiones.

Lo gestione como lo gestione, no imagino ninguna forma de
que el SGBD pueda mantener una conexión sin consumir
recursos.

, para reducir el tráfico de red

Esto se soluciona mucho mejor usando un SGBD distribuido.

Los datasets se podrían considerar como un antepasado

prehistórico de

un SGBD distribuido.


Por ejemplo si estamos trabajando con un SGBD

distribuido y hacemos

una consulta SQL que afecta a datos que se encuentran en

el PC local

el tráfico de red sería 0 y seguimos con todas las

ventajas de estar

conectados.

En el caso en que solo la mitad de los datos se

encontrasen en el PC

local solo haría falta traer la mitad de los datos, y

esto se haría de

forma totalmente automática y transparente. Si repetimos

la consulta y

el PC local tiene capacidad suficiente entonces el

trafico de red

sería otra vez 0. Un SGBD distribuido funciona como una

caché super

sofisticada.

Es decir que el programador trabajaría de la misma forma

que si

estuviese programando una aplicación de escritorio y

sería el SGBD el

que se encargase de minimizar el tráfico de red sin que

tuviesemos que

preocuparnos de nada. Esto no es ciencia ficción, es un

problema

resuelto hace décadas.

¿Pero qué producto ha resuelto este problema de una forma
eficiente?. Dices que no es ciencia ficción, pero no
conozco ninguna solución del tipo que estás planteando,
que funcione correctamente. No comprendo de que manera
podrían manejarse la concurrencia, u otros problemas
similares, de forma eficiente en un sistema como el que
plantéas. Al menos si comparamos con la eficiencia de una
gestión explícita como la de DataSet. La transparencia es
muy interesante siempre y cuando el precio a pagar no sea
excesivamente alto, tal y como parece el caso.

Pero incluso sin tener en cuenta los problemas de
eficiencia. Imaginemos una aplicación que se ejecuta
sobre un portatil, que vuelca datos a un SGBD una vez al
dia. ¿De qué forma se podrían controlar los problemas de
concurrencia de forma transparente?. La transparencia es
un concepto muy bonito en informática, pero en muchas de
ocasiones es imposible o impracticable.

On Mon, 20 Dec 2004 18:51:49 -0800, "anonymous11"
wrote:

Eso se soluciona mejor con un "middleware". Pero ¿Por
que querríamos minimizar las conexiones abiertas?
¿Para ahorrarnos dinero en las licencias?
Creo que en algunos casos hacer esto puede considerarse
como un fraude.

Segun lo que lee de tu posicion piensas que seria mejor
trabajar con conexiones abiertas en vez de desconectadas
como propone el modelo de ado.net y que es SGBD carge con
el peso de las mismas.

No necesariamente. Si el SGBD gestiona mal las conexiones puede que
haga falta minimizar el número de conexiones abiertas.

Pero en nuestras aplicaciones que
podrian tener cientos o miles de usuarios concurrentes
esto seria una peso bastante grande no es mejor en este
sentido que se conecten y desconecten para ahorrar
recursos no solo del SGSB sino de toda la PC???

Pues depende, las conexiones siempre hay que gestionarlas de alguna
manera, y si el SGBD lo hace bien es un trabajo que nos ahorramos.

No entiendo bien este punto, acaso dices que cada cliente
debe tener una copia local de su BD. por que eso seria
carisimo!. No se si me explicas mejor.

Si, algo parecido, pero no tendría por que ser carísimo.

Y tampoco tendría que tener una copia entera de la BD, bastaría con
los datos más comunmente utilizados y que los demás datos se
importasen automáticamente cuando hiciesen falta.

Un SGBD distribuido es algo mucho más potente, flexible y sofisticado
que una vulgar caché de datos.

Saludos

On Tue, 21 Dec 2004 02:04:10 -0800, "Tristan"
wrote:

Lo gestione como lo gestione, no imagino ninguna forma de
que el SGBD pueda mantener una conexión sin consumir
recursos.

Por supuesto que tiene que consumir recursos, pero si implementas tu
propio sistema de conexiones tu también los vas a consumir.

La cuestión está en si vale la pena no utilizar el sistema de
conexiones del SGBD y utilizar otro.

Si el sistema de conexiones del SGBD fuese muy eficiente nunca valdria
la pena usar otro.

Por ejemplo si el SGBD utilizase un protocolo UDP muy optimizado
podrian mantenerse miles de conexiones con muy poca utilización de
recursos.

En lo que estoy de acuerdo es en que si el SGBD no lo hace bien,
entonces lo tendríamos que solucionar nosotros.

Una forma de solucionarlo es con un SGBD distribuido con varios
servidores, así la carga de las conexiones se distribuiría entre los
distintos servidores y ellos se mantendrían sincronizados
automáticamente.

Hay soluciones como para aburrir.

¿Pero qué producto ha resuelto este problema de una forma
eficiente?.

¡Ahí está el problema!

Es justo de lo que me estoy quejando.

MS, en lugar de desarrollar lo que te he contado, ha desarrollado los
datasets, y no creo que haya sido por falta de recursos.

que funcione correctamente. No comprendo de que manera
podrían manejarse la concurrencia, u otros problemas
similares, de forma eficiente en un sistema como el que
plantéas.

Pues está todo perfectamente resuelto desde hace mucho tiempo, si
quieres te doy referencias de libros.

Lo que faltan son ingenieros de software que lean la literatura
científica.

Al menos si comparamos con la eficiencia de una
gestión explícita como la de DataSet. La transparencia es
muy interesante siempre y cuando el precio a pagar no sea
excesivamente alto, tal y como parece el caso.

No habría que pagar ningún precio, sino que ganaríamos mucha
eficiencia.

Pero incluso sin tener en cuenta los problemas de
eficiencia. Imaginemos una aplicación que se ejecuta
sobre un portatil, que vuelca datos a un SGBD una vez al
dia. ¿De qué forma se podrían controlar los problemas de
concurrencia de forma transparente?.

Ya, este caso es un poco especial. Lo ideal sería que el sistema
pudiese conectarse siempre que se necesitase. Pero con los datasets
tendrias exactamente los mismos problemas y tendrías que desarrollar
la aplicación utilizando herramientas muy rudimentarias.

Estos problemas se podrían solucionar con un diseño apropiado de la
base de datos (no del SGBD).

Por ejemplo ¿Que situación concreta te parece que podría ser un
problema?

La transparencia es
un concepto muy bonito en informática, pero en muchas de
ocasiones es imposible o impracticable.

No estoy muy de acuerdo, son muchas menos ocasiones de las que la
gente se imagina. Pero lo triste es cuando es perfectamente posible y
no se hace, como en este caso.


Saludos
Alfredo

Hola,

"Alfredo Novoa" escribió en el mensaje
news:

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

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.

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

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. 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. (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).

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.

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.

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

Saludos,

Juan Carlos Paramá