Cual es el mejor acceso a FireBird/InterBase?; cuanto mejor??

Combat-F2D · #1 11-08-2004

Después de que alguno de los colegas del foro me largase una pequeña bronquita por no participar últimamente en ellos, lo cual es totalmente cierto, lo reconozco, me he decidido a postear lo siguiente:

Existen muchas preguntas en los foros acerca de cual es la manera más eficaz, o la menos mala, de acceder a FB/IB en Delphi, mediante que componentes, forma, etc.; muchas han sido las respuestas, pero pese a ello, le he metido algo de tiempo al asunto, creando una pequeñita aplicación sobre testeo de los más conocidos o empleados (por lo menos hasta donde yo sé).

Los implicados han sido (todo bajo WINDOWS):

•S.O.: Windows 2000 Profesional SP4 (ojo, tengo alguna actualización de Windows Update con SP5), corriendo FB 1.5 (ojo, no está actualizado a la 1.51) como servicio de arranque automático, siendo la misma máquina como cliente y servidor; se hace notar que he intentado que las diversas pruebas se realizases en las mismas condiciones de máquina, para que los resultados obtenidos en las diversas pruebas se puedan cotejar con más credibilidad.

•Lenguaje: DELPHI 6, con SP2.

•DBEXPRESS: Exactamente el que acompaña a la versión de Delphi citada.

•BDE: Exactamente la que acompaña a la versión de Delphi citada, es decir, la 5.01.

•ZEOS: son la versión zeosdbo-6.1.5-stable, aunque si no estoy mal informado ya ha salido la zeosdbo-6.5.0-alpha ( www.zeoslib.net, www.sourceforge.net/projects/zeoslib)

•IBX: Exactamente la versión 6.08 (trae soporte para IB 7.01) (codecentral.borland.com/codecentral/ccweb.exe/listing?id=20258). Habrá que tener en cuenta el ya NO soporte para FireBird, OJOOOOO.

•FIBPlus: exactamente la versión 5.3.0 Release; es una pena que se tenga que pagar licencia por ella, pues como veremos va cañon; de su página se puede descargar la trial/demo, así que para su prueba vale (www.devrace.com ).

•UIB: Unified Interbase v1.2h (2004-05-06) (prdownloads.sourceforge.net/synedit/synedit-cvs-2004-04-27.zip )

•ODBC mediante BDE: versión Firebird/InterBase(r) driver 1.02.00.64 de fecha 01JUL2004 ( www.ibphoenix.com).

•ODBC mediante ADO: mismo controlador ODBC anterior y ADO en la versión del Delphi y WINDOWS instalada (no sé en este momento la numeración).

•IBO: es la versión 11/24/2003 Sub-Release 4.3 Aa, es la trial que se puede descargar de la Web de www.ibobjects.com

Desconozco hasta el momento si existirán otros componentes y similares, es por eso que sólo empleara estos para el testeo.

Para la prueba he creado una Base da Datos consistente en:

1.Dos (2) Tablas
2.Dos (2) Disparadores (Trigger).
3.Un (1) Procedimiento Almacenado (Store Procedures).
4.Un (1) Generador.

La estructura quedaría de la siguiente manera (los metadatos han sido obtenidos mediante la utilidad IBManager de EMS (www.ibmanager.com) ):

Código SQL [-]CREATE DATABASE 'C:\testeo\testeo.gdb'
USER 'sysdba' PASSWORD 'la de siempre'
PAGE_SIZE 4096
DEFAULT CHARACTER SET WIN1251;

CREATE GENERATOR SACARID ;
SET GENERATOR SACARID TO 1;

CREATE TABLE TABLA1 (
    ID INTEGER NOT NULL,
    CAMPO1 VARCHAR (50) CHARACTER SET WIN1251 NOT NULL COLLATE WIN1251,
    CAMPO2 VARCHAR (50) CHARACTER SET WIN1251 NOT NULL COLLATE WIN1251);

CREATE TABLE TABLA2 (
    ID INTEGER NOT NULL,
    VALOR1 VARCHAR (50) CHARACTER SET WIN1251 NOT NULL COLLATE WIN1251);

ALTER TABLE TABLA1 ADD CONSTRAINT PK_TABLA1 PRIMARY KEY (ID);
ALTER TABLE TABLA2 ADD CONSTRAINT PK_TABLA2 PRIMARY KEY (ID);

ALTER TABLE TABLA2 ADD CONSTRAINT FK_TABLA2 FOREIGN KEY (ID) REFERENCES TABLA1 (ID) ON DELETE CASCADE ON UPDATE CASCADE;

CREATE INDEX FK_TABLA2 ON TABLA2 (ID);
CREATE UNIQUE INDEX IDX_TABLA1 ON TABLA1 (CAMPO1);
CREATE UNIQUE INDEX IDX_TABLA11 ON TABLA1 (CAMPO2);
CREATE UNIQUE INDEX IDX_TABLA2 ON TABLA2 (VALOR1);
CREATE UNIQUE INDEX PK_TABLA1 ON TABLA1 (ID);
CREATE UNIQUE INDEX PK_TABLA2 ON TABLA2 (ID);


SET TERM ^ ; 
CREATE PROCEDURE METEENTABLA2 (
    VALORDEID INTEGER)
AS
BEGIN
  EXIT;
END
^


ALTER PROCEDURE METEENTABLA2 (
    VALORDEID INTEGER)
AS
DECLARE VARIABLE IDENSTRING VARCHAR(20);
begin
  IDENSTRING = 'Valor de Id: ' || CAST(:VALORDEID as varchar(20));
  INSERT INTO  tabla2  ( tabla2 . id ,  tabla2 . valor1 ) values(:VALORDEID, :IDENSTRING );
  suspend;
end
^

CREATE TRIGGER INSERTAENTABLA2 FOR TABLA1 ACTIVE
AFTER INSERT POSITION 0
AS
begin
   execute procedure meteentabla2(new. id );
end
^

CREATE TRIGGER TABLA1OPTENERID FOR TABLA1 ACTIVE
BEFORE INSERT POSITION 0
AS
BEGIN
    if (new. id  is null) then
    new. id  = gen_id( sacarid , 1);
END
^

SET TERM ; ^

Si observamos ambas tablas están relacionados entre sí por la foreign key creada, de tal manera, que el proceso es el siguiente:

Cuando introducimos un registro o fila en la TABLA1, antes de ello salta el disparador de tal manera que su ID, el de la PrimaryKey , se obtiene mediante un Generador; posteriormente al darse el alta, salta otro disparador, el cual ejecuta el Procedimiento Almacenado que desencadena otra alta en la TABLA2 relacionada con esta TABLA1.

Con ello lo que he pretendido ha sido que el Server, en este caso de FB 1.5 ejecute en cierta manera las diferentes posibilidades con las que cuenta, TABLAS, Generadores, Trigger y StoreProcedures; tal vez también debería haber tenido en cuenta alguna UDF, View, Excepcion, pero creo que para valorar un poco el asunto, puede valer.

Una vez creada la BD, procedo a crear una pequeñita aplicación que consiste en lo siguiente:

Provoco un bucle indefinido hasta 250.000, con lo que pretendo que la aplicación genere estas 250.000 altas en la TABLA1, provocando los consiguientes procesos comentados más arriba; se hace notar que cada 500 altas, provoco un Commit en la BD.

Código:

El código de dicha aplicación no lo puedo implementar aquí debido a la limitación de los 10.000 caracteres del post.

Este código ha sido adaptado a la forma de trabajar de cada componente

Cada aplicación sobre componentes diversos, los he lanzado 3 veces cada uno en condiciones de máquina similar (recién arrancada, para ser lo más parecidas posible, caralladas del WIN aparte); una vez obtenidos los tiempos de proceso, he hecho una simple media aritmética y los resultados han sido los siguientes expresados, claro, en segundos:

Cita:

DBEXpress - 80
BDE - 148
ZEOS - 309
IBX - 64
FIBPlus - 64
UIB - 86
BDE/ODBC - 195
ADO/ODBC - 211
IBO - 75

Cabe citar que en la configuración de los ZEOS, he tenido que emplear la configuración para FB 1.0, pues la que traía para 1.5 me daba problemas; me imagino que en la versión actualizada que comenté arriba lo habrán solucionada; lo desconozco.

En base a ello, estos han sido los datos que he podido obtener.

Espero, si tal, que ello sirva para determinar en un momento dado, cual es la mejor opción ha tener en cuenta a la hora de buscar rapidez para este tipo de proceso de altas masivas en automático; lo ideal hubiese sido poder realizar en una red de varios equipos ejecutándola simultáneamente, pero eso es lo que tengo por casa, y por desgracia ya no estoy currando para disponer de una red a mi gusto.

Así mismo, si un día me decido, probaré los mismos a la hora de realizar unos SELECT selectivos y un poco complicadillos, pues a lo mejor la cosa puede varias con respecto a la actual.

Otra cuestión es que es mejor como Server FB, WIN o Linux???; la cosa está clara……; pero cuanta más clara????, eso lo dejo para otro post que colocaré en el foro, ( www.clubdelphi.com/foros/showthread.php?t=13209 )pues este ya ha sido muy largo. Búscalo, puede valer la pena que pierdas un rato leyéndolo.

Espero que los moderadores, como Cadetill y compañía no me riñan por alargarme tanto. Si os parece conveniente, pegarle un tajo o mejor publicarlo en la sección de Intebase, si Emilio lo cree conveniente.

guillotmarc · #2 25-08-2004

Muy completo.

Felicidades Julio.

plasma · #3 31-05-2006

Me agradó este post porque habemos muchos que apenas empezamos a utilizar Firebird, sin haber siquiera pasado por IB y andamos a ciegas, sin saber que componentes utilizar para empezar, en estos momentos estoy trabajando con MDO, desafortunadamente no aparece entre los componentes utilizados en tus pruebas y no sé que tan bueno es en comparación con los ya expuestos. Posteriormente lo sabremos.
Saludos!.

Delfino · #4 31-05-2006

Cita:

Habrá que tener en cuenta el ya NO soporte para FireBird, OJOOOOO.

Este soporte existe con los MDO, q supongo daran el mismo resultado q los IBX y Fib+ ya q todos derivan de los Free IB..

Casimiro Notevi · #5 31-05-2006

Cita:

Empezado por plasma

Me agradó este post porque habemos muchos que apenas empezamos a utilizar Firebird, sin haber siquiera pasado por IB y andamos a ciegas, sin saber que componentes utilizar para empezar, en estos momentos estoy trabajando con MDO, desafortunadamente no aparece entre los componentes utilizados en tus pruebas y no sé que tan bueno es en comparación con los ya expuestos. Posteriormente lo sabremos.
Saludos!.

Delfino tiene razón en lo que comenta, aunque puedes probarlo por tí mismo, ahí tienes el script de creación de las tablas para hacer las pruebas, puedes probar con mdo y nos cuenta, puedes compararlo con ibx, que lo tendrás instalado por defecto.

Combat-F2D · #6 01-06-2006

yo tambien espero ese resultado, agradeciendo el mismo

Sick boy · #7 06-06-2006

Yo tambien trabajo con los MDO.

Trataré de probarlos contra IBX y DBExpress, y esta tarde posteo los resultados.

Saludos

Sick boy · #8 06-06-2006

No he podido realizar las pruebas, el script me da un error que estoy intentando resolver. Asi que he utilizado otra base de datos que ya tenia (mucho más compleja) con una tabla similar. La base de datos es más compleja, pero la tabla que utilizo se parece bastante a la de tu prueba.

Un dato es que el page_size de mi tabla es de 1024, mientras que el tuyo es de 4096. No se muy bien si eso puede tener algo que ver.

Debo de estar haciendo algo mal, ya que para insertar 2500 registros necesito 22 segundos con los MDO.

Con los IBX no lo puedo probar, ya que no me abre las tablas de FireBird 1.5

Utilizas querys??

Yo he puesto un query con dos parametros, los cuales voy modificando dentro del bucle, asignando el valor de la variable inttostr(i).

Los parametros se los paso con parambyname()

Vamos, que el intento ha sido un fracaso total. Si alguien puede decirme como puedo volver a intentarlo estoy dispuesto a pasar más tiempo haciendo pruebas.

PS: Los MDO van de lujo, que nadie piense que son mucho más lentos porque no soy capaz de realizar este test correctamente.

ASAPLTDA · #9 18-06-2006

Estos componentes permiten migrar de bde casi en forma transparente los uso hace mas de un ano y son muy buenos
No solamente permiten usar interbase/firebird sino oracle db2 bases de datos odbc/oledb con los mismos componentes, solamente cambiando el tipo de base de datos

plasma · #10 22-06-2006

He trabajado poco con Firebird por lo tanto no tomen esta opinión en cuenta para tomar la decisión de usar o no usar determinados componentes, mejor usen, evalúen y decidan.

Mi comentario es acerca de una aplicación que creé, ésta cuenta con 30 tablas, cuentan en promedio con 20 campos cada una, la mayoría de ellos son lógicos, (de hecho son enteros sólo definí un dominio), estos campos cuentan con valores default (0) comencé usando los MDO, para empezar por ser software libre, por su facilidad de uso y similitud con los componentes BDE que son los componentes que mas usé; pero tuve problemas al trabajar con estos valores default, esperaba que los componentes asignaran estos valores en caso de que el usuario del software no los ingresara, no lo hacían.

Supuse que debía hacer persistentes los campos de las tablas, asignarles un valor default a cada uno de los campos y con eso se solucionaría, lo hice pero no ocurrió lo esperado, pudiera haber olvidado algo pero lo dudo.

Tenía a la mano un setup de los IBObjects, (sé que es diferente la maduréz que tienen ambos conjuntos de componentes), lo instalé y me di a la tarea de crear un pequeño programa para probar los valores default con estos componentes, no hice mas que asignar a la base de datos (TIBODatabase) el alias de mi DB, una transaction y la tabla de prueba, la active y empecé a hacer pruebas, para mi sorpresa los valores default ahí estaban, no hubo la necesidad de hacer campos persistentes. La cantidad de propiedades de los componentes es enorme, pero con los valores que traen es suficiente y trabajan muy bien desde entonces(hace como un mes jeje), trabajo con los IBO y me agradan aunque la curva de aprendizaje si está má prolongada que con otros compos, no estoy usando ni la quinta parte de lo que ofrecen.
Si saben como configurar los que se asignen los valores default en los campos de las tablas MDO les pido me ayuden a resolverlo, más que nada por aquellos que puedan tener un problema similar.

Nos vemos luego.