TTable VS TQuery
 

Saludos a todos, me gustaría iniciar un debate sobre los Objetos TTable y TQuery.

Hasta ahora yo siempre había sido partidario de la utilización de objetos TTable para la edición de datos (Mantenimientos...) y objetos TQuery para la consulta de datos de sólo lectura (listados, comprobaciones, etc...), pero la verdad es que cada vez más estoy basando mis aplicaciones en SQL, de esta manera me he dado cuenta que los objetos TQuery, gracias a la propiedad RequestLive pueden comportarse como una tabla con la ventaja de que tienes toda la potencia de manejar el SQL de la consulta como quieras. De hecho poco a poco le veo menos ventajas al uso de objetos TTable y comienzo a plantearme el no utilizarlos.

Por supuesto, si Borland diseñó estos componentes y los ha mantenido hasta la actualidad habrá sido por una buena razón, de manera que supongo que habrá algo que tengan los objetos TTable como ventaja sobre los objetos TQuery.

Me gustaría saber la opinión de los aforados sobre el tema, quizás haya información sobre estos componentes que desconozca.

Un saludo a todos.

TDworD

Si estás usando bases de datos de buró como Paradox lo cierto es que las componentes TTable están diseñadas para ello y serán más eficientes que los TQuery. He notado, por ejemplo, que las consultas SQL para Paradox no utilizan los índices definidos en las tablas a diferencia de las componentes TTable y en muchas situaciones la diferencia en rendimiento es bastante notable (mucho mejor TTable que TQuery).

Por otra parte pienso que más que debatir este punto, mejor sería pensar en dejar de usar el BDE (obsoleto, en desuso y descontinuado) y utilizar servidores reales de bases de datos en donde, en efecto, siempre será mejor utilizar consultas SQL.

Como varias gentes han expresado anteriormente, habiendo servidores robustos como Firebird- que son gratuitos - ¿para que seguir usando este tipo de bases de buró?

// Saludos

Pienso que tienes razón, yo ahora estoy utilizando MySQL con componentes Zeos, y una ve saltado el obstáculo de dominar un poco el funcionamiento de los componentes y las instrucciones específicas de MySQL la verdad es que va de cine. Hasta ahora siempre había trabajado con paradox y utilizaba las tablas, pero la verdad es que el TQuery y MySQL me ofrecen mucha más estabilidad y potencia.

Dudaba de si el componente TTable tubiera alguna cualidad que desconociera pero parece que no.

Sobre lo que comentas, la verdad es que el tema de usar el BDE yo si lo veo adecuado para aplicaciones pequeñas en las que la base de datos no es lo fundamental. En ese caso instalar un servidor de base de datos en el cliente puede ser muy pesado para una tarea sencilla y si la aplicación requiere una pequeña base de datos en local BDE puede ser una buena solución.

Por ejemplo hace poco realicé una aplicación para gestionar torneos, en dicha aplicación no utilicé base de datos porque no lo consideré necesario, al final quedaba un ejecutable de unos 412 Kb, poco después he visto una aplicación que hacía unas funciones similares hecha en Java y contra MySQL, entre la máquina virtual Java, el servidor MySQL y la aplicación el instalable alcanzada más de los 40 Mb, incluso aunque mi aplicación hubiera requerido de una base de datos podía haber instalado BDE y aún así dudo que hubiera superado los 3Mb el instalable consa importante si tenemos en cuenta que son aplicaciones pensadas para descargarse de internet.

Un saludo a todos y gracias por la respuesta roman.

TDworD

Una instalación básica del BDE, según acabo de checar, se lleva más de 6MB. Con FireBird puedes usar el servidor "embebido" que ocupa, según veo, 1.5 MB. MySql también tiene servidor embebido y dudo que ocupe tanto como el BDE.

Y si el manejo de datos es muy sencillo se puede optar incluso por el uso de client data sets.

// Saludos

Pues el principal problema del BDE, a parte de estar discontinuado, es que requiere mucha memoria RAM.

La ventaja, porque alguna tenía que tener es que es un motor capaz de conectarse con distintos tipos de Tablas, Paradox, Dbase, Fox, Interbase, Access, Sysbase, Oracle....

A veces necesitamos cuadrar una facturación por ejemplo en Paradox, con una contabilidad ajena, por ejemplo hecha en Fox y la versatilidad del motor en cuanto a tipos de tablas lo permite.


Un Saludo.