Conviene usar DBExpress?

[ivan022481]

Cuando empezamos con delphi los primeros componetes que usamos para acceso a DB fueron los Interbase, luego BDE, ya que me cambie a SQL Server, luego ADO (para no usar ODBC). Siempre trabaje bien en todos estos, ahora estoy probando DBExpress en Delphi 2007 para conectarme a una BD en MySQL. Todo bien, pero al momento de agregar una grilla (componente que usamos mucho en los sistemas que diseñamos en nuestra empresa) me emite un error que solo maneja datos de manera unidireccional. Leyendo en el foro encontre una solucion que al ser valida me pone en duda la utilizacion de los DBExpress, por lo menos para MySQL. La solución es utilizar un ClientDataSet enlazado a un TDataSetProvider y este mismo enlazalo al TSQLQuery, despues se añade un TClientDataSet y se enlaza al TDatasetProvider :D. Me pregunto, ¿cada vez que quiera utilizar una grilla voy a tener que utilizar todos estos componentes?(y eso que solo probe con una grilla, no se otros componentes de acceso a datos). Es ahi cuando me viene la pregunta que figura como titulo. Antes con solo enlazar un TQuery o TTable a un TDataSource y la grilla enlazada al TDataSource "voila", tenia los datos en la grilla.
Otra solucion alternativa a DBExpress (por lo menos para utilizar una BD de MySQL) es usar Zeos, pero todavia no vienen para Delphi 2007. Me gustaria que me cuenten su experiencia a ver si nos convencemos de utilizar DBExpress. Saludos.

[AzidRain]

Mejor usa Zeos, son mucho más sencillos y bastante confiables. Además traen los fuentes. Por ejemplo para hacer lo de la grilla solo necesitas:

Un TZConnection (que hace la conexión y puede compartirse con otros componentes que lo requieran)

Un TZQuery (el query en si)

Un TDataSource (para accesar a los datos del query)

Y listo.

El TZQuery se comporta como cualquier tabla de Delphi, soporta Edit, Post, Insert, LookUp, Locate, etc.

[ivan022481]

Coincido totalmente AzidRain, pero por ahora lo Zeos no estan para la version 2007 de Delphi. Usamos Zeos en su momento y sabemos de su efectividad y facil uso, pero lamentablemente por ahora no hay librerias para Delphi 2007.
¿Vos fuiste el que hizo un manual de instalacion para Zeos?

[maro]

Hola,

Llevo mucho tiempo usando DBExpress.

Es cierto que son componentes más complicados de usar.

La ventaja es que al ser componentes unidireccionales ofrecen mayor velocidad en la consulta de datos y ofrecen un rendimiento más adecuado para aplicaciones de 3 capas.

Ten en cuenta, que los componentes que mencionas (tClientDataset, TDatasetProvider , etc) son componentes diseñados para trabajar en 3 capas y separar (físicamente) la capa SQL (donde pondríamos los componentes de DBExpress + TDatasetProvider) de la capa cliente (donde pondríamos los tClientdataSets)

Lógicamente no te los recomiendo para aplicaciones de 2 capas, donde esta configuración es más lenta y complicada de usar.

Un Saludo.

[Delfino]

Lógicamente no te los recomiendo para aplicaciones de 2 capas, donde esta configuración es más lenta y complicada de usar.
Puedes detallar un poco mas tu razonamiento?
pq es mas lenta? y donde estara la complicacion?
Aqui (http://delphi.about.com/od/database/a/dbexpressguide.htm) se dice lo contrario..

[maro]

Hola,

Comentar, que es mi opinión y no está basada en una documentación técnica (puesto que yo soy autodidacta :) ), sino, en mi experiencia al trabajar con esta técnica, por lo cuál puedo equivocarme fácilmente.

Igualmente quisiera dejar claro que soy partidario de trabajar con estos componentes, y es obvio ya que todos mis proyectos los fabrico con dbExpress + DataSnap.

Considero que es más lento por una sencilla razón: para obtener los mismos resultados utilizamos mayor número de procesos.

Disculpen que esto pueda ser un poco espeso:

Suponiendo que utilizamos Socket Server:

El usuario solicita registros -> ClientDataset -> SocketConnection (empaquetado y codificación de la petición) -> Transmisión por Internet o red -> Socket Server (desempaquetado de petición, interpretación) -> Servidor SQL -> tDatasetProvider -> tSLQDataset -> Servidor BD (apertura de cursor y retorno de TODOS los registros solicitados). -> tSQLDataset -> tDatasetProvider -> Servidor SQL (Empaquetado de todos los registros, incluyendo estructura de campos, restricciones, etc. Esto se hace con un Whlile para recorrecorer todos los registro y por cada registro un For para recorrecr todos los campos de la consulta y añadiendolos al paquete que se retornará) -> Socket Server (interpretación y retorno al la capa Cliente) -> Transmisión por Internet o red (un solo paquete indistintamente de su tamaño, provocando posibles cuellos de botella, demoras, etc) -> SocketConection (interpretación, desempaquetado, de nuevo While's y for...) -> ClientDataset (resultado de la consulta cargada en memoria Ram, muchos ClientDataset, con muchos registros: consumo de recursos - Desbordamiento de memoria Ram) -> presentación de datos al usuario.

Posibles errores:
Son muchos los inconvenientes de una mala gestión de esta tecnica.
Realmente lo que tenemos en un ClientDataset es una copia de los registros que hipoteticamente tenemos en la BD. Si por algún motivo se manipulan los datos en la BD (procedimientos almacenados, triggers, otros usuarios) podemos obtener error de conciliación de datos.

La complicación real, está en que hay conocer muy bien como funciona un modelo en tres capas para desarrollar correctamente nuestro software.
Si pasamos a programar de 2 a 3 capas el programador tendrá inventar nuevas técnicas para realizar procesos que eran muy simples en 2 Capas (como puede ser la asignación de valores a los campos PRIMARY KEY de las tablas)


No obstante, no me mal interpreten, con una tecnica muy depurada recomiendo fabricar aplicaciones en 3 capas antes que en 2 capas.

Pero, simplemente es mi opinión.

Un Saludo.