Ir al contenido


Foto

Firebird 2.5 RC 2


  • Por favor identifícate para responder
25 respuestas en este tema

#1 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 06:42

Firebird 2.5 por fin ya está prácticamente a punto de ser liberado. Ha salido su Release Candidate 2, que se espera que en unas semanas se convierta en la versión final (si no aparece ningún bug).

http://www.ibphoenix...p_download_test

Esta versión está orientada para establecer la nueva arquitectura interna de Firebird (unificando las arquitecturas SuperServer, Classic y Embedded).

A pesar de ello, también lleva alguna que otra mejora, más "terrenal", que hacen que merezca la pena actualizarse.

Entre otras :

*) Se pueden lanzar consultas a bases de datos externas. Se ha ampliado el comando EXECUTE STATEMENT para que ahora la consulta pueda realizarse sobre otra base de datos (lo cual permite incluso montar una consulta cruzada entre bases de datos, desde un procedimiento almacenado).

*) Ya se pueden gestionar los usuarios de Firebird desde sentencias SQL (en lugar de vernos obligados a utilizar el comando de DOS gsec).

*) Se pueden utilizar expresiones regulares con el operador SIMILAR TO. Un ejemplo vale más que mil palabras : phone similar to '\([0-9]{3}\) [0-9]{3}\-[0-9]{4}' escape '\'

*) se pueden manejar transacciones desde PSQL. Es decir en un procedimiento almacenado/trigger puedes iniciar y finalizar tus propias transacciones.

*) Ya se pueden usar sin problemas consultas con la condición WHERE SOME_COL = ? OR ? IS NULL  (hasta ahora era precios un CAST para que el motor las reconociera).

*) ... ... ... (collation unicode no sensible a mayúsculas, nuevas funciones para cadenas UUID, ALTER COLUMN para campos calculados, cancelación asíncrona de conexiones, la librería cliente fbclient.dll ahora es thread-safe, más información en las tablas de monitorización, ..., ...)

Saludos.
  • 0

#2 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 08:58

Firebird 2.5 por fin ya está prácticamente a punto de ser liberado. Ha salido su Release Candidate 2, que se espera que en unas semanas se convierta en la versión final (si no aparece ningún bug).

http://www.ibphoenix...p_download_test

Esta versión está orientada para establecer la nueva arquitectura interna de Firebird (unificando las arquitecturas SuperServer, Classic y Embedded).

A pesar de ello, también lleva alguna que otra mejora, más "terrenal", que hacen que merezca la pena actualizarse.

Entre otras :

*) Se pueden lanzar consultas a bases de datos externas. Se ha ampliado el comando EXECUTE STATEMENT para que ahora la consulta pueda realizarse sobre otra base de datos (lo cual permite incluso montar una consulta cruzada entre bases de datos, desde un procedimiento almacenado).

*) Ya se pueden gestionar los usuarios de Firebird desde sentencias SQL (en lugar de vernos obligados a utilizar el comando de DOS gsec).

*) Se pueden utilizar expresiones regulares con el operador SIMILAR TO. Un ejemplo vale más que mil palabras : phone similar to '\([0-9]{3}\) [0-9]{3}\-[0-9]{4}' escape '\'

*) se pueden manejar transacciones desde PSQL. Es decir en un procedimiento almacenado/trigger puedes iniciar y finalizar tus propias transacciones.

*) Ya se pueden usar sin problemas consultas con la condición WHERE SOME_COL = ? OR ? IS NULL  (hasta ahora era precios un CAST para que el motor las reconociera).

*) ... ... ... (collation unicode no sensible a mayúsculas, nuevas funciones para cadenas UUID, ALTER COLUMN para campos calculados, cancelación asíncrona de conexiones, la librería cliente fbclient.dll ahora es thread-safe, más información en las tablas de monitorización, ..., ...)

Saludos.


Vaya veo que este motor de bases de datos aunque a un paso muy lento va mejorando. Es grandioso saber que estas características por fin son includias en Firebird. Desde hace mucho tiempo la falta de estas me hacián considerar a este motor más de "Escritorio" que cliente servidor. Aún faltan muchas más cosas pero todo pinta que algún día llegará al nivel de los grandes.

Saludos¡¡¡¡¡
  • 0

#3 enecumene

enecumene

    Webmaster

  • Administrador
  • 7.419 mensajes
  • LocationRepública Dominicana

Escrito 09 febrero 2010 - 09:11

Así es amigo Poli, y esperemos que cuando llegue el día aún siga siendo gratuito :p, muchas gracias por la noticia amigo Marc.

Saludos.
  • 0

#4 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 09:38

Así es amigo Poli, y esperemos que cuando llegue el día aún siga siendo gratuito :p, muchas gracias por la noticia amigo Marc.


Yo no me preocuparía en absoluto. La verdad es que la licencia de Firebird es muy distinta a la de MySQL. Por eso Firebird siempre será libre, ya que no puede ser comprado, ni cerrado, ...

Otra cosa es que alguien haga un Fork de Firebird, lo mejore, y lo venda con licencia comercial, sin hacer público el código de sus mejoras (como hicieron los de Yaffil, un antiguo fork de Firebird). Pero para mi, eso es una ventaja de la gran permisividad de la licencia de Firebird (y que nos permite a todos utilizarlo en nuestras aplicaciones comerciales).

Saludos.
  • 0

#5 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 09:47

Hola poliburro.

Vaya veo que este motor de bases de datos aunque a un paso muy lento va mejorando. Es grandioso saber que estas características por fin son includias en Firebird. Desde hace mucho tiempo la falta de estas me hacián considerar a este motor más de "Escritorio" que cliente servidor. Aún faltan muchas más cosas pero todo pinta que algún día llegará al nivel de los grandes.


Tengo una curiosidad, ¿ te importaría comentar que limitaciones te encuentras en Firebird que te muevan a considerarlo una base de datos de escritorio ?.

La verdad es que Firebird ya cubre con creces mis necesidades (y ya lo hacía con Firebird 1.0), aún así agradezco las mejoras que van haciendo, puesto que te facilitan la vida al hacer necesario escribir menos código para conseguir el mismo resultado.

En tu caso, ¿ que necesidades tienes que no cubra Firebird ?, quizás te pueda ayudar y haya soluciones válidas para alguna de ellas que tú aún no conozcas.

NOTA: Por cierto, tienes razón en que la evolución de Firebird es muy lenta. Y es que hasta ahora han destinado casi todo su tiempo a la reprogramación del motor interno (en Firebird 1.5 pasaron todo el código de C a C++ para facilitar su desarrollo posterior, en Firebird 2.0 reprogramaron el motor para que sea escalable y pueda ejecutarse aprovechando múltiples CPU's, en Firebird 2.5 han unificado las distintas arquitecturas existentes: Classic, Superserver y Embedded). Esperemos que con el siguiente Firebird 3.0, termine este larguísimo proceso de reingeniería del motor de Firebird que empezaron nada más liberarse el código de Interbase 6.0, y por fin puedan centrarse en añadir características nuevas en la base de datos.

Saludos.
  • 0

#6 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.448 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 09:52

Hola

En mi vida de programador solo he usado 2 bases de datos en mis desarrollos, Paradox y Firebird y realmente me han servido para todo lo que he necesitado, ni mas ni menos :).

Y si efectivamente, la licencia de Firebird es el menor de sus problemas. ;)

Salud OS
  • 0

#7 eduarcol

eduarcol

    Advanced Member

  • Administrador
  • 4.483 mensajes
  • LocationVenezuela

Escrito 09 febrero 2010 - 10:05

Hola

En mi vida de programador solo he usado 2 bases de datos en mis desarrollos, Paradox y Firebird y realmente me han servido para todo lo que he necesitado, ni mas ni menos :).

Y si efectivamente, la licencia de Firebird es el menor de sus problemas. ;)

Salud OS


IDEM, y aun tengo aplicaciones de Paradox funcionando, así que no es tan mala como dicen
  • 0

#8 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 10:10

Hola poliburro.


Vaya veo que este motor de bases de datos aunque a un paso muy lento va mejorando. Es grandioso saber que estas características por fin son includias en Firebird. Desde hace mucho tiempo la falta de estas me hacián considerar a este motor más de "Escritorio" que cliente servidor. Aún faltan muchas más cosas pero todo pinta que algún día llegará al nivel de los grandes.


Tengo una curiosidad, ¿ te importaría comentar que limitaciones te encuentras en Firebird que te muevan a considerarlo una base de datos de escritorio ?.

La verdad es que Firebird ya cubre con creces mis necesidades (y ya lo hacía con Firebird 1.0), aún así agradezco las mejoras que van haciendo, puesto que te facilitan la vida al hacer necesario escribir menos código para conseguir el mismo resultado.

En tu caso, ¿ que necesidades tienes que no cubra Firebird ?, quizás te pueda ayudar y haya soluciones válidas para alguna de ellas que tú aún no conozcas.

NOTA: Por cierto, tienes razón en que la evolución de Firebird es muy lenta. Y es que hasta ahora han destinado mucho tiempo a la reprogramación de todo su motor interno (en Firebird 1.5 pasaron todo el código de C a C++ para facilitar su desarrollo posterior, en Firebird 2.0 reprogramaron el motor para que sea escalable y pueda ejecutarse aprovechando múltiples CPU's, en Firebird 2.5 han unificado las distintas arquitecturas existentes: Classic, Superserver y Embedded). Esperemos que con el siguiente Firebird 3.0, termine este largo proceso de reingeniería del motor de Firebird que empezaron nada más liberarse el código de Interbase 6.0, y por fin puedan centrarse en añadir características nuevas en la base de datos.

Saludos.


Ok amigo :) agradezco tu interes en mi consideración y expongo las características que me han hecho no usar firebird en mis desarrollos

1 - No incluye soporte de conectividad entre diferentes bases de datos dentro del mismo servidor ( algo como "Select From BaseDeDatos.Tabla1 left join OtraBaseDeDatos.Tabla2)

2 -  No incluye soporte de conectividad entre diferentes bases de datos de diferentes servidores ( Algo como Select from servidorlocal.mibasededatos.tabla1 left join servidorremoto.mibasededatos.tabla2)

3- Soporte transaccional en procedimientos almacenados

4- conectividad implícita con diferentes origenes de bases de datos ( algo como Select * from mitabla lef join OrigenAccess.Tabla)

5- Herramienta ETL nativa que permita la importacion o exportación de y para diferentes orígenes de datos. (traer o enviar datos desde excell, access, oracle, csv, dbase, etc ect)

6- Soporte xml nativo ( Interpretar Xml para generar datasets o generar Xml a partir de datasets)

7 - Disponibilidad de funciones escalares buil-it muy limitada.

8 - No ofrece un proveedor OleDb nativo que me permita integrarlo con otro motor de base de datos.

9 - No permite separar los archivos de índices y datos con el fin de obtener mayor velocidad en las búsquedas. (esta característica te permitiría colocar los índices en un arreglo raíd veloz y los datos en un arreglo de menor velocidad. Incrementando la velocidad de las búsquedas)



Adolecer de estas características no la hacen un mal motor, al contrario sigue siendo una excelente opción para nuestros desarrollos, tanto como lo es access o paradox o dbase. Pero aceptando que tiene limitantes no deberia compararse con los grandes. (Oracle, Postgress, MsSql,Db2, Informix)

Saludos amigo.

  • 0

#9 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.448 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 10:21

Yo como siempre digo.

DEPENDE, DEPENDE, DEPENDE

En mi caso me han sido más que suficiente ya que la mayoría de mis desarrollos están orientados a sistemas monousuarios para lo cual utilizo Paradox y actualmente utilizo Firebird para que esas mismas aplicaciones las puedan "consultar" desde otras computadoras, quiero decir, que son sistemas muy pequeños que no requieren de mas.

Por el contrario Edgar si requiere de un motor que le proporcione todas las características que menciona.

Yo creo que la mejor base de datos es la que te proporciona lo que necesitas así sea Access, DBase, Paradox, Firebird, MySQL, etc.... :)

Salud OS
  • 0

#10 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 10:30

Yo como siempre digo.

DEPENDE, DEPENDE, DEPENDE

En mi caso me han sido más que suficiente ya que la mayoría de mis desarrollos están orientados a sistemas monousuarios para lo cual utilizo Paradox y actualmente utilizo Firebird para que esas mismas aplicaciones las puedan "consultar" desde otras computadoras, quiero decir, que son sistemas muy pequeños que no requieren de mas.

Por el contrario Edgar si requiere de un motor que le proporcione todas las características que menciona.

Yo creo que la mejor base de datos es la que te proporciona lo que necesitas así sea Access, DBase, Paradox, Firebird, MySQL, etc.... :)

Salud OS



Exacto, no lo has dicho de mejor manera mi estimado Eliseo. Esa es la razón por la que yo siempre he visto a firebird como un motor orientado a entornos chicos o de escritorio. Nunca para entornos críticos. Eso por supuesto no desmerece al motor, creo que es muy bueno haciendo su chamba, tanto como lo son otros motores del mismo nivel.

Saludos cordiales.

  • 0

#11 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.448 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 10:49

Bueno

No dije que Firebird fuera para sistemas pequeños, solo digo que cada quien usa el motor que mas le ajusta :p :D :D :D

Salud OS
  • 0

#12 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 09 febrero 2010 - 11:05

Hola,
Un tanto fuera de tópico... tengo una preguntita para Marc:
¿A qué te refieres cuando dices que las arquitecturas están "unificadas"?

Yo me he quedado en F1.5 y no le he dado una ojeada profunda a las versiones 2.x (Más que nada se debe a que uso D6 y los IBX y por motivos de seguridad y compatibilidad) por lo que no estoy bien al tanto de todos los cambios que se han estado llevando a cambio.

Si tienes unos minutos te agradecería que me explicases, o citases una fuente, al respecto. Me tiene intrigado.

Saludos,
  • 0

#13 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 11:30

Hola Delphius

Un tanto fuera de tópico... tengo una preguntita para Marc:
¿A qué te refieres cuando dices que las arquitecturas están "unificadas"?


Es que en Firebird hay dos arquitecturas distintas, la Classic y la Superserver (cuando lo instalas tienes que escoger una u otra).

Estas arquitecturas indican la forma en que trabaja el motor. En la arquitectura Classic, cada vez que se conecta un usuario a una base de datos, se inicia un nuevo hilo de ejecución exclusivo para él, que queda a la espera de solicitudes, y se le asigna un espacio de memoria, de esta forma cada conexión trabaja de forma totalmente independiente. En cambio en la arquitectura Superserver, hay un único hilo de ejecución atendiendo a las solicitudes de usuario, y cada vez que recibe una consulta, inicia un hilo de ejecución para calcular esos datos, y que finaliza una vez entregados los datos al cliente.

La arquitectura Superserver es más moderna que la Classic (de ahí los nombres). Pero cada una tiene sus ventajas. La arquitectura Superserver es más rápida y tiene menor consumo de memoria, pero no escala tan bien como la Classic. En la arquitectura Classic se pueden ir conectando tantos usuarios como se quiera, que como se crea un hilo de ejecución exclusivo para cada uno de ellos, el rendimiento no se degrada.

El caso es que ahora habrá una sola arquitectura, que combinará los puntos fuertes de cada una de las anteriores.

NOTA: Te dejo una pequeña comparativa (está algo anticuada, puesto que es para Firebird 1.5), con Firebird 2.0 la arquitectura Classic ya se puede considerar madura en Windows también.

http://www.firebirds...c-or-super.html

Saludos.
  • 0

#14 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 09 febrero 2010 - 11:45

Hola Marc,
Te agradezco que te tomaras el tiempo.

Eso que comentas sobre ambas arquitecturas y sus diferencias lo sé. Y de lo poco que estuve informándome sobre los avances y mejoras de Classic también tengo entendido que hoy en día es un producto muy maduro.

No me queda muy en claro a que te refieres con que ahora habrá una sola... ¿Es decir, ya no habrá Classic ni SuperServer sino una X? :^) *-) 8-)

Por lo que estuve viendo en en enlace que pusiste en el primer hilo ahora hay SuperClassic (off-topic: ¿Y Esta cuando apareció? :o) ¿Es a esta nueva arquitectura a la que tu denominas "Unificada"?

A lo que voy es que no me queda claro... si ahora sólo habrá SuperClassic (lo que indicaría que ya no habrá más Classic ni SuperServer) o por el contrario... aparte de SuperServer, y Classic (y considerando la opción de Embebed) habrá está 4ta.

Espero que se entienda.

Saludos,
  • 0

#15 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 12:26

Gracias, por contestar. Por lo que veo, me temo que Firebird nunca va a ser adecuado para tus necesidades, puesto que hay algunos puntos que creo que no tienen ninguna intención de implementarlos.

Ok amigo :) agradezco tu interes en mi consideración y expongo las características que me han hecho no usar firebird en mis desarrollos

1 - No incluye soporte de conectividad entre diferentes bases de datos dentro del mismo servidor ( algo como "Select From BaseDeDatos.Tabla1 left join OtraBaseDeDatos.Tabla2)

2 -  No incluye soporte de conectividad entre diferentes bases de datos de diferentes servidores ( Algo como Select from servidorlocal.mibasededatos.tabla1 left join servidorremoto.mibasededatos.tabla2)


Sí, esto puede resultar ser muy útil en momentos puntuales. Van avanzando en este aspecto. Gracias al EXECUTE STATEMENT sobre otras bases de datos, ahora se puede conseguir, aunque no de forma directa (tienes que programar un procedimiento almacenado que vaya consultando los datos en las distintas bases de datos, y los devuelva debidamente cruzados). Se preveé que en Firebird 3 ya se puedan hacer directamente estas consultas cruzadas.

3- Soporte transaccional en procedimientos almacenados


Nunca lo he necesitado, pero entiendo que algunos lo necesitéis, y por lo que veo por eso lo han añadido.

4- conectividad implícita con diferentes origenes de bases de datos ( algo como Select * from mitabla lef join OrigenAccess.Tabla)


Habrá que esperar a Firebird 3. Según tengo entendido está previsto de que admita conexiones de todo tipo de fuentes de datos (imagino que usará fuentes ODBC o JDBC).

NOTA: Aunque esto me parece que sobretodo es útil para la importación y exportación de datos. Y ya hay muchas herramientas externas para hacer estos procesos (aunque está claro que todo lo que puedas hacer desde la comodidad del SQL, bienvenido sea).

5- Herramienta ETL nativa que permita la importacion o exportación de y para diferentes orígenes de datos. (traer o enviar datos desde excell, access, oracle, csv, dbase, etc ect)


No, no la tiene y no la va a tener. ¿ Porqué necesitas que sea nativa ?, hay una buena cantidad de herramientas de terceros que permiten hacerlo y son muy buenas, además de ser también libres algunas (como la que uso habitualmente: IBDataPump).

No la van a programar porqué ya hay una gran cantidad de herramientas disponibles, y prefieren centrarse en el Servidor. Además quieren que la instalación sea lo más compacta posible (es una gozada tener el instalador en solo 4Mb, es muy cómodo para las instalaciones remotas). Si empiezan a añadir herramientas de Administración (que tampoco lleva ninguna, y hay que utilizar herramientas de terceros como IB-Expert) el tamaño del instalador se dispararía.

6- Soporte xml nativo ( Interpretar Xml para generar datasets o generar Xml a partir de datasets)


Otra cosa que tampoco va a llevar Firebird a medio plazo. Y es que siempre que les preguntan sobre el tema, los chicos de Firebird responden que esto es una función que debe implementar el cliente. Y es que realmente es muy fácil de implementar en tu aplicación (yo utilizo ClientDatasets con un XMLMapper).

7 - Disponibilidad de funciones escalares buil-it muy limitada.


Esto ha mejorado mucho desde Firebird 1. En cada versión van integrando más funciones internas (hasta el punto de que las UDF's que vienen ya no son necesarias). Pero realmente está muy mal documentado, tienes que ir consultando todas las Release Notes de todas las versiones para saber que funciones tienes disponibles.

Además te puedes implementar tus propias funciones (yo lo hago con subconsultas a procedimientos almacenados), aunque Firebird 3 ya tendrá una sintaxis específica para definir funciones de usuario.

8 - No ofrece un proveedor OleDb nativo que me permita integrarlo con otro motor de base de datos.


No, hay algunos disponibles de terceros (como el IBProvider) pero ninguno propio del proyecto Firebird, y no van a sacarlo. De forma nativa proporcionan drivers ODBC, JDBC y un .NET Provider. No hay ninguna intención de sacar un driver OleDB y tienes que escoger entre el de terceros (IBProvider) o bien la pasarela OleDB for ODBC.

9 - No permite separar los archivos de índices y datos con el fin de obtener mayor velocidad en las búsquedas. (esta característica te permitiría colocar los índices en un arreglo raíd veloz y los datos en un arreglo de menor velocidad. Incrementando la velocidad de las búsquedas)


Interesante, aunque tampoco conozco que tengan ninguna intención de implementarlo. Y es que trabajan duro en mejorar el funcionamiento de los índices y del optimizador SQL, pero hasta donde yo sé no van a implementar esto (supongo que prefieren dedicarlo a mejorar los algoritmos anteriores). Además la intención de Firebird es que sea una base de datos con mantenimiento cero, por lo que dudo de que implementen características como esta, que precisan de un Administrador para la configuración y mantenimiento de la Base de Datos.

Adolecer de estas características no la hacen un mal motor, al contrario sigue siendo una excelente opción para nuestros desarrollos, tanto como lo es access o paradox o dbase. Pero aceptando que tiene limitantes no deberia compararse con los grandes. (Oracle, Postgress, MsSql,Db2, Informix)


Si está claro que nunca podrá competir con los recursos que dedican Oracle, IBM o Microsoft a sus bases de datos. Pero lo importante es que lo que hace lo hace muy bien, y es más que suficiente para muchas empresas (y no solo para aplicaciones de escritorio).

NOTA: ¿ Seguro que Firebird no juega en la misma liga que PostgreSQL ?.

Saludos.
  • 0

#16 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 12:38

Hola Delphius.

Hola Marc,
Te agradezco que te tomaras el tiempo.

Eso que comentas sobre ambas arquitecturas y sus diferencias lo sé. Y de lo poco que estuve informándome sobre los avances y mejoras de Classic también tengo entendido que hoy en día es un producto muy maduro.

No me queda muy en claro a que te refieres con que ahora habrá una sola... ¿Es decir, ya no habrá Classic ni SuperServer sino una X? :^) *-) 8-)

Por lo que estuve viendo en en enlace que pusiste en el primer hilo ahora hay SuperClassic (off-topic: ¿Y Esta cuando apareció? :o) ¿Es a esta nueva arquitectura a la que tu denominas "Unificada"?

A lo que voy es que no me queda claro... si ahora sólo habrá SuperClassic (lo que indicaría que ya no habrá más Classic ni SuperServer) o por el contrario... aparte de SuperServer, y Classic (y considerando la opción de Embebed) habrá está 4ta.

Espero que se entienda.

Saludos,


Pues sí, la arquitectura unificada es la han venido a llamar SuperClassic.

Se ve que en Firebird 2.5 hay que escoger entre Classic, SuperServer o SuperClassic (o la Embedded, que viene a ser una SuperServer que solo acepta una conexión local).

La verdad es que tampoco lo sabía, pensaba que la Classic y SuperServer desaparecerían, pero no es el caso.

http://www.firebird....hp?storyid=2856

Dado que la versión 2.5 es solo una versión de transición hacía Firebird 3.0, veremos como queda la cosa definitivamente en FB 3.

Saludos.
  • 0

#17 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 09 febrero 2010 - 12:49

Por cierto, se ve que la arquitectura SuperClassic no es una fusión de la SuperServer y la Classic, sino una versión mejorada de la Classic que aún escala mejor para atender a más usuarios (cada conexión crea un thread exclusivo independiente y no un proceso exclusivo independiente, las memorias siguen siendo independientes), y que teóricamente debería ser la arquitectura base de Firebird 3.
  • 0

#18 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 09 febrero 2010 - 12:54

Saludos.

No he querido pronunciarme acerca del tema, porque esta es una de las historias de nunca acabar.

Existen informaciones acerca de que Firebird maneja un monto de datos, que muchas empresas han decido mudarse a Firebird en vez de tener una de "mayor nivel" montado.

Todas los motores de BD evolucionan, a Firebird le ha faltado $$$ (y si recuerdan el articulo que salio sobre su posible costo si se fuera a crear ahora), deben de recordar que la mayoría de los desarrolladores no están al 100% del tiempo programando, muchos de ellos le dedican el "tiempo libre" que tienen.

Firebird posee características que tanto Oracle y MS SQL Server han implementado en sus ultimas versiones.

No pude conseguir la fuente, pero si recuerdo claro que el articulo se hacía llamar Back to the future, en este se explica el supuesto boom de SQL Server 2005 sobre la nueva implementación de una nueva tecnología en el manejo de registros y esta no es más que la arquitectura multi generacional que Firebird posee desde su ancestro.

En cuanto a Oracle, una situación palpada por mí, Oracle en todas sus versiones previa a la 11 no crea un indice al momento de crear una clave foránea, este feature lo posee Firebird desde sus ancestro.

Obviamente Firebird no puede ser comparada al 100% con Oracle, MS SQL Server, Informix, DB2 y demás; pero de algo si estoy bastante claro Firebird no debe (ni es) ser considerada una BD para escritorio.

Sí respeto el pensar de cada quien, porque este mercado es así, pero al momento de referirnos a Firebird debemos de hacerlo con cierta altura y respeto, es cuanto.  :cool:
  • 0

#19 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 09 febrero 2010 - 12:59


En cuanto a Oracle, una situación palpada por mí, Oracle en todas sus versiones previa a la 11 no crea un indice al momento de crear una clave foránea, este feature lo posee Firebird desde sus ancestro.

Obviamente Firebird no puede ser comparada al 100% con Oracle, MS SQL Server, Informix, DB2 y demás; pero de algo si estoy bastante claro Firebird no debe (ni es) ser considerada una BD para escritorio.

Sí respeto el pensar de cada quien, porque este mercado es así, pero al momento de referirnos a Firebird debemos de hacerlo con cierta altura y respeto, es cuanto.  :cool:


Totalmente de acuerdo con los tres párrafos. :) Un saludo cordial.


  • 0

#20 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 09 febrero 2010 - 01:00

Entiendo.

En resumen:
1. Con la aparición de 2.5 existe una tercera opción llamada ClassicServer (y parece que pinta muy buena), 4ta si contamos a la versión Embebed como una arquitectura más (aunque nunca oficialmente se la ha asumido como tal).
2. Hasta el momento no sa sabe que será de Classic ni SuperServer (y por tanto, de Embebed :p ¡que insistente que estoy!)

"Conociendo" la prolijidad y el cuidado que tienen por compatibilidad hacia atrás creería que no se animarían a eliminar estas dos arquitecturas... Admito que no estoy informado de las últimas novedades y de como estarán las cosas (con decir que recién caigo en la idea de que existe esta nueva arquitectura) Pero si hay algo que rescatar es que siempre han puesto esfuerzo en mantener las cosas bien.

Las correcciones (al menos algunas) que se consiguieron con la aparición de 2.x se trasladaron a 1.5 y a 1.0... Creería, y sería de esperar, que cualquier mejora que lograran con SuperClassic la extrapolaran en SuperServer y Classic.

Pero por el otro lado se sabe que las cosas van muy lento y están un tanto apurados, y presionados convengamos, en añadir las mejoras que tanto se han estado pidiendo y anunciando que quieren llegar a la 3.0 lo más pronto posible. Esto se podría "traducir" quizá a que ya no sea económico seguir manteniendo varias arquitecturas.

Esto me recuerda a un artículo que había leído en un blog en el que se decía que el proyecto Firebird estaba ya un tanto estancado y pobre.

Como bien dices, habrá que esperar a la 3.0 para ver que se dice.

Saludos,
  • 0




IP.Board spam blocked by CleanTalk.