23 respuestas en este tema

[cannabis]

Utilizo MDO desde hace algún tiempo.

Al tratar de actualizar los componentes, me encuentro que es la misma versión con la que trabajo (febrero de 2006)

¿Cuáles componentes me recomiendan? (y gratuitos, claro está) Desarrollo con D7.

Gracias.


Salud.

[enecumene]

Pues en mi caso trabajo Firebird con Zeos pero también te puedo recomendar los IBX (Pestaña Interbase)

Saludos.

[eduarcol]

tengo ya algún tiempo trabajando con Zeos y no he tenido ningun tipo de problemas, pero eso no seria una opinion tecnica, habria que hacer pruebas de desempeño a ver que ocurre.

[cannabis]

Gracias compañeros.

Los descargo, los pruebo y les comento más tarde.


Salud.

[Al González]

¡Hola!

Cuando empecé con cliente-servidor, lo hice con Firebird en Delphi 7.  Y usando los componentes nativos IBX más que nada por desconocer otras alternativas.  Así estuve varios años, pero desde hace tres me pasé a dbExpress (DBX) combinados con TClientDataSet (también en Delphi 7).  Y no he tenido problema alguno para manejar Firebird con estos componentes que también son nativos, pero más avanzados.

Es definitivamente mi recomendación por las siguientes razones:

1. Ser la tecnología de bases de datos más desarrollada por los ingenieros fabricantes de Delphi.
2. Cero dependencias con DLLs del sistema operativo.
3. Poder cambiar de base de datos sin hacer demasiados cambios en el código.

Sólo hay que incluir un par de DLLs en la distribución de una aplicación hecha con dbExpress y TClientDataSet: el controlador de dbExpress y MIDAS.dll.

Es mi apuesta y entre más conozco ese binomio menos pasa por mi mente usar otra tecnología.

Saludos.

Al González.

[Rolphy Reyes]

Saludos.

La combinación que indica Al es muy buena, no la he utilizado para Firebird directamente sino para SQL Server y Oracle y funciona de maravilla.

Pero en mi caso particular (para desarrollos personales) utilizo FibPlus, porque entiendo que soportan mejor Firebird que los demás. También puedes "emular" la combinación DbExpress + ClientDataSet, ya que FibPlus tienen un derivado de ClientDataSet entonces sería TpFIBDataSet + TpFIBClientDataSet.

La única pega es que son de paga pero vale lo que cuesta.

[egostar]

Hola

Yo desde que uso Firebird (hace solo unos meses), uso los IBX, por dos razones, por desconocimiento de otras tecnologías y la otra por mi constante paranoia por no usar componentes de terceros, hasta el momento no he tenido problemas al usar estos componentes pero pienso que debe ser porque no me he metido con complejidades en mis requerimientos de acceso a base de datos.

Lo mas que he usado con Firebird son los procedimientos almacenados, no uso disparadores ni vistas, tal vez esa sea la razón por la que no requiero ni he visto necesidad de usar otros componentes.

Salud OS

[Rolphy Reyes]

Lo mas que he usado con Firebird son los procedimientos almacenados, no uso disparadores ni vistas, tal vez esa sea la razón por la que no requiero ni he visto necesidad de usar otros componentes.

Mientras utilices dentro de tus Procedimientos, Vistas y Disparadores (aunque no los uses en la actualidad) el ANSI no tendrás problemas, ahora bien cuando utilices sentencias propias del gestor es posible que tengas algunos inconvenientes.

Cuando me inicie en la programación estuve como tú en el aspecto de no usar componentes de terceros, pero dada cierta situación tuve que utilizarlos por suerte para mi fueron los de DevExpress que son tremendos.  De ahí en adelante empece a utilizarlos pero siempre me aseguro de que la compañía ofrezca soporte y sean sólidos; con esos requisitos basta para mi.

[Kipow]

Yo tengo ya algunos años utilizando IBX + Firebird, pero por cuestiones de compatibilidad este año inicio la migracion de mi aplicacion principal a DBX, motivo pues actualmente estoy trabajando ya con la version 2.1.1 de Firebird y hasta el momento ningun problema, pero no quiero confiarme y que las IBX me vayan a dar algun problema para las siguientes versiones (aunque ya con esta tuve algunos contratiempos principalmente con el IBEvent), otra situaciones que es quiero aprovechar para mejorar el rendimiento de mi aplicacion, utilizando los ClientDataset, ya pase un par de opciones de las mas pesadas y realmente consegui un rendimiento superior al 200% ademas de que los clientdataset se cargan en memoria no seria nada dificil meterle Multihilos para cargar datos en momentos idle. Otra ventaja de utilizar los DBX es que como bien mencionaron con unos pequeños cambios ya estas montando tu aplicacion en otras bases de datos, por ejemplo no se ve nada mal la convinacion Delphi + Oracle 10g (express) con limitantes pero creo que superables.

[cannabis]

Gracias a todos por su ayuda y comentarios.

Probé dbExpress y ClientDataSet con una tabla de 100,000 registros para ser desplegados en un dbgrid. El resultado fue excelente.

Utilizo únicamente queries, creados en modo de ejecución, para consultar y actualizar la base de datos.

El cambio a dbx será muy fastidioso ya que tendré que crear un ClientDataSet y un DataSetProvider por cada query y utilizo muchos.

Para el registro de labores de los empleados se crean los siguientes queries:

Empleados.- Trabajadores de la(s) finca(s) (300 o 400)

Actividades.- Actividades (100 - 200) que realizan los empleados.

Finca.- Hacienda/Rancho donde se realiza la actividad

Cuadrilla.- Grupo de trabajo al que pertenece el empleado en cuestión.

Paño.- Sector de la finca donde fue realizada la actividad.

Labores del Empleado.- Despliegue de las labores que ha realizado el empleado (la tabla contiene las labores de todos los empleados y con un año de uso los registros llegan a ser cerca de 300,000.

Bitácora.- Se registra las actividades del usuario/capturista, para controlar errores.

y otros cinco o seis queries más.

Estoy modificando y mejorando la aplicación. Así que aprovecharé para hacer pruebas con los diferentes componentes.

Les comentaré más adelante los resultados.

Gracias de nuevo.


Salud.

[Kipow]

Con solo esos querys yo me reiria (perdon pero es cierto) yo tengo planeado en unas semanas empezar mi migracion a n-tier con datasnap+dbx tengo que trabajar con alrededor de 300 tablas eso si es un trabajal, pero ni modo todo sea para mejorar.

[cadetill]

Hola

Si queréis un comparativo de componentes de acceso a Firebird desde Delphi, en ClubDevelopers (perdón por la propaganda a los miembros de este buen sitio) tenéis una que compara:

# DBEXPRESS
# BDE
# ZEOS
# IBX
# FIBPlus
# UIB
# ODBC mediante BDE
# ODBC mediante ADO
# IBO

Es un artículo del 2004, pero imagino que los componentes habrán mejorado todos a mejor o se habrán estancado, así que puede ser muy orientativo. Las conclusiones.... que cada uno saque las suyas propias

Si queréis estoy dispuesto a realizar esa prueba con los componentes actualizados y FB 2.1 para dar datos más recientes.

Espero que os sirva

Nos leemos

Vsss

[eduarcol]

no te preocupes por la publicidad, el asunto es colaborar entre los dos sitios 

[egostar]

Hola,

Está muy interesante el artículo, me he permitido traer la estadística de las pruebas realizadas por el compañero

Julio Nogueira Fandiño
CombatF2D
07 de octubre de 2004

delphi

Componente	Tiempo (sg.)
 
DBEXpress	 80
BDE		148
ZEOS		309
IBX		 64
FIBPlus		 64
UIB		 86
BDE/ODBC	195
ADO/ODBC	211
IBO		 75

Como bien dice nuestro amigo cadetill habrá que considerar la fecha de las pruebas, solo agrego que por lo que he leido, Firebird en su última versión busca mayor compatibilidad y eso me parece digno de ser observado en referencia al uso de IBX

Salud OS

[Rolphy Reyes]

Hola,

Está muy interesante el artículo, me he permitido traer la estadística de las pruebas realizadas por el compañero

Julio Nogueira Fandiño
CombatF2D
07 de octubre de 2004

delphi

Componente	Tiempo (sg.)
 
DBEXpress	 80
BDE		148
ZEOS		309
IBX		 64
FIBPlus		 64
UIB		 86
BDE/ODBC	195
ADO/ODBC	211
IBO		 75

Como bien dice nuestro amigo cadetill habrá que considerar la fecha de las pruebas, solo agrego que por lo que he leido, Firebird en su última versión busca mayor compatibilidad y eso me parece digno de ser observado en referencia al uso de IBX

Salud OS

También debemos de recordar que a partir de la versión 2 se ha mejorado mucho el performance de la BD.  Entre los arreglos realizados esta lo referente a la decisión de escoger el indice adecuado.

[cannabis]

Con solo esos querys yo me reiria (perdon pero es cierto) yo tengo planeado en unas semanas empezar mi migracion a n-tier con datasnap+dbx tengo que trabajar con alrededor de 300 tablas eso si es un trabajal, pero ni modo todo sea para mejorar.

<modo Sufrimiento ON>
Después se preguntan porqué los de espíritu débil abandonamos la programación
<mod Sufrimiento/OFF>

Mi estimado Kipow, no tengo la más remota idea de que tipo de aplicación llegaría a utilizar 300 tablas.
Imagino que el desarrollo abarca diferentes sistemas concentrados en una sola aplicación.

¿Podrías dar detalles? Gracias.


Salud.

[Kipow]

jaja, pues es un ERP. completo abarcando todas las areas de una empresa comercial/industrial/servicios (inventarios, facturacion, caja, compras, clientes, proveedores, servicios, contratos, produccion, contabilidad general, activos fijos, bancos, nomina/planilla, proyectos, y mi ultima criatura un modulo de replicacion). eso si todo normalizado como se debe exceptuando casos muy especificos donde el rendimiento si es notable entonces obvio una que otra regla de normalizacion, pero tambien podria decirte que son Años de desarrollo en los cuales ha ido creciendo poco a poco la aplicacion y sigue. bien calculo que para fin de año 2009 ya tengo al menos otras 20-25 tablas mas segun la planificacion.

[Al González]

Mi estimado Kipow, no tengo la más remota idea de que tipo de aplicación llegaría a utilizar 300 tablas.
Imagino que el desarrollo abarca diferentes sistemas concentrados en una sola aplicación.

Sólo por mencionar un dato que puede resultar curioso, algunos ERPs de los que hay en el mercado tienen más de 30 mil tablas.

Saludos.

Al González.

[Delphius]

Mi estimado Kipow, no tengo la más remota idea de que tipo de aplicación llegaría a utilizar 300 tablas.
Imagino que el desarrollo abarca diferentes sistemas concentrados en una sola aplicación.

Sólo por mencionar un dato que puede resultar curioso, algunos ERPs de los que hay en el mercado tienen más de 30 mil tablas.

Saludos.

Al González.

NO me asustes Al, ¿30 mil? Concebir 300 a 500 es aceptable. Pero de 300 a 30 mil hay un paso enorme.
Discúlpame amigo pero me cuesta creer esa cifra. Sin ofender, ni traer polémica, ¿podrías darnos un ejemplo concreto?

Antes de tener tantas tablas en una única base de datos, optaría por considerar tener múltiples bases de datos con pocas tablas.

Saludos,

[Al González]

NO me asustes Al, ¿30 mil? Concebir 300 a 500 es aceptable. Pero de 300 a 30 mil hay un paso enorme.
Discúlpame amigo pero me cuesta creer esa cifra. Sin ofender, ni traer polémica, ¿podrías darnos un ejemplo concreto?

Parece que en este sitio se ofrece una lista completa de las tablas de SAP: http://www.mundosap....ead.php?t=1214  Sólo que hay que registrarse.

Y aquí encontrarás una pequeñita muestra de cómo están organizadas algunas tablas de ese ERP: http://www.de-jabu.c...g=tablas-de-sap

Antes de tener tantas tablas en una única base de datos, optaría por considerar tener múltiples bases de datos con pocas tablas.

Al contrario, se gana mayor consistencia de la información al estar toda en una sola base de datos.  Y es más aprovechable.


Solemos asustarnos con estas cifras porque estamos acostumbrados a tener el control personal "total" de una base de datos.  Pero en un ERP comercial el trabajo en equipo es más que necesario.  Es rarísimo que una sola persona conozca los nombres de todas las tablas de SAP, es importante que sean varias personas las que trabajen alrededor de ella o al menos contar con una excelente documentación.

Yo también me sorprendí al principio, pero después de analizarlo lo veo bastante lógico.  Con uno de esos ERPs, cada cosa que uno mencione dentro de una empresa estaría representada por una entidad en la base de datos.  Si una empresa consigue ese estado "ideal", podríamos decir que se encuentra lista para sistematizar absolutamente todos sus procesos.

Por otro lado supongo que una parte significativa se va en tablas del sistema (metadatos) y en tablas clasificadoras (clases, categorías, tipos de...).

Un saludo.

Al.