Cita:
Empezado por mcs
[..] Soy tozudo como una mula, y seguía con mi idea que los IBDAC no podían estar TAN mal programados.
|
No es que estén mal programados, es que no hay otra forma de hacerlo. Ten en cuenta que, por ejemplo, en una tabla dbf, hay una cabecera donde indica la estructura de los datos, la longitud que ocupa cada registro y el total de registros, entre otros. Si quieres ir al último registro sólo tienes que avanzar el puntero (UltimoRegistro*OcupacionDeCadaRegistro). Que quieres ir al registro 1000, pues multiplicas 1000*OcupacionDeCadaRegistro y posicionas el puntero en ese lugar del fichero.
Pero una base de datos relacional no tiene nada que ver con una tabla plana. En una RDBMS hay registros (y campos) con longitud variable, no existe un primer registro y un último registro, todo depende del orden con el que los queramos presentar. No podemos ir al último registro porque no sabemos cual es, ¿el último ordenado por fecha, por código, por nombre, etc.?, cuando hacemos un select traemos sólo unos pocos registros, por ejemplo, si los presentamos en un dbgrid normalmente serán justos los que quepan en pantalla, luego se irán trayendo los siguientes según avanzamos en el dbgrid, y si le damos "ir al final" entonces se traerá todos los registros.
Son filosofías muy distintas de trabajo.
Cita:
|
Empezado por mcs
Código:
SELECT COUNT(*) FROM table;
SELECT * FROM table;
|
¿Por qué IBDAC hace eso?, está claro, para que "parezca" que es una tabla "normal", primero cuenta los registros que hay, además lo hace muy ineficientemente (el asterisco), podría usar uno sólo de los campos que tenga índice, sería mucho más rápido. Y una vez que sabe cuantos registros hay, o sea, ha tenido que ir hasta el último campo para traérselos todos, es ahora cuando hace un select de todos los campos, otra vez el *, y sigue la ineficiencia elevada al cuadrado
Pero, repito, no es que esté mal programado, es que si quieres simular una tabla plana con un RDBMS no tienes otra solución.
La otra solución es hacer lo mismo que FreeIB, FIBL, FIBplus, etc. ¡¡¡no tener componente TTable!!!
Estas cosas se aprende estudiando bastante en profundidad las bases de datos, su código fuente, descubres cosas curiosas, trucos interesantes y algunos fallos tremendos. Las bases de datos son una de mis aficiones, me gusta inspeccionar cómo están hechas, hace muchos años hice un sistema de bases de datos como el de los dbf, al que añadí control multiusuario para red local. Y años más tarde hice otro sistema de gestión de bases de datos (un sistema Btree+) también con control de bloqueos, multiusuario, red, journaling, etc. en lenguaje C, lo utilicé en algunos proyectos propios y la verdad es que funcionaban muy bien estable y muy rápido.
Lástima que los perdí en un disco defectuoso, estoy hablando de la época 1990 a 1995, ya ha llovido