[[Delphius]]

Empezado por Chris

Delphius, noto que siempre recalcas en mis opiniones. Creo que te debo caer mal :P

No, no me caes mal... pero dejémoslo en que tienes la facilidad de exasperarme.
Si hay algo que no me agrada es que venga un tipo que se dice alabar algo pero resulta que se auto apuñalada y busca meter el vardo (problemas para los argentinos) a escondidas.

Empezado por Chris

Hombre, no sugiriendo que uno sea mejor que el otro.

El sólo hecho de hacer esos llamados a comparación es separar, clasificar... y de decir quien es mejor y cual es el peor.

Empezado por Chris

Cada uno de los motores tiene lo suyo y su ámbito óptimo. No elegirías Postgre o Firebird para manejar una simple agenda de contactos. Tampoco usarías SQLite para manejar un sitio como Tweeter.

No estoy pidiendo que Firebird sea Postgre. Lo repito. Tonto sería yo si pidiera a SQLite que fuera como Oracle. Pedir este tipo de cosas creo que solo los tontos lo hacen. Si SQLite tuviera todo lo de Oracle perderíamos ese maravilloso motor de datos liviano y ligero para llevar.

Repito, cada base de datos tiene su nicho y es pericia del desarrollador elegir el motor más adecuado para el menester. Pieso que sería ingenuo de un desarrollador elegir siempre el mismo motor para própositos y usos muy, pero muy distintos.

A ver... estoy de acuerdo en que uno debe aplicar un buen análisis de caso de estudio para decir que es lo más viable. Pero yendo al caso ¿Que es lo que no hace viable a FB en algunos escenarios?

Quieres algo monousuario y liviano: Firebird Embeded; aunque si existe la restricción de que sea multiplataforma allí si hay que mirar más.
Necesitas algo más adecuada para Windows: Firebird SuperServer
Necesitas algo más adecuado a Linux: Firebird Classic o SuperClassic

Necesitas algo grande: Firebird

Si hay algo que tiene FB es que tiene diferentes sabores para adaptarse a varios escenarios. Es lo suficiente flexible y escalable como para ir desde el monosuario a una compleja red.
¿No es eso maravilloso? Pidele lo mismo a MySQL, PostgreSQL o a SQLite a ver que te dicen.

Empezado por Chris

Por eso uno tiene que saber que tiene uno y que le falta al otro.

Y saber cuando callar, y hacer una crítica constructiva y cuando permitirse hablar. Hablaste de unas supuestas falencias, viejas, de FB. Te he dicho que FB a mejorado y tu le seguiste dando por algo del pasado; como lo de seguridad.
¿O es que te parece poco y nada el avance de 2.1 a 2.5 y ahora con lo que se viene a 3.0?
Tu tiraste una visión en la que te quedas como en que FB nunca mejorará... y seguirá siendo un juguete que está bajo la sombra de PostgreSQL.
Date cuenta Chris que los aspectos de seguridad, redes, procedimientos almacenados y otras "características" que señalas no son limitaciones, ni hacen de FB un producto inmaduro.

Si realmente quieres hacer una crítica constructiva pongamos a la luz los avances de FB y PostgreSQL desde su concepción ¿Quien avanzó más y más rápido en los años que lleva?
PostgreSQL es el primer proyecto Open Source (corrijanme si me equivoco) y lleva casi 30 años. Firebird por su parte recién cumplió su década.
FB a avanzado en sus 10 años muchísimo más rápido que PostgreSQL en sus 30. Si eso no es para destacar ¿que mierda es?

Naturalmente FB debe seguir madurando, pero ¿pensemos si? Te parece poca cosa lo hecho por el proyecto Firebird? ¿Eso no suma no?

Si FB fuera un juguete, ¿porqué hay empresas que apuestan cada vez más? ¿Porqué ha venido ganando premios en SourceForje como uno de los proyectos más alentadores?

Empezado por Chris

La gente de Postgre que debe estar viniendo a FB, seguramente no supieron hacer una buena elección al principio, o tal vez no existía Firebird en ese entonces.

Lees pero no etendés. ¡Parte del equipo de desarrollo de PostgreSQL es quien se pasó a Firebird!
Además cuando dije que MySQL y PostgreSQL le deben favores me refiero justamente a una de las cabezas del equipo de Firebird gentilmente cedió su experiencia y recomendaciones a MySQL y PostgreSQL; si... así es colaboró en dichos proyectos. Lo cierto es que MySQL no sería lo que es sino fuera por la ayuda que brindó Steve Summers. La historia fue más o menos así: "Oye Steve te necesito aquí porque me quedé trabado. ¿Me das una mano? Claro que te pagaré"

Empezado por Chris

Hace ya un par de años, se me encomendó elegir un nuevo motor de base de datos para un sistema ya existente. Descarté a MySQL por su licencia dual. También, aunque no lo creas, descarté a PostgreSQL porque era como utilizar un camión para mover una pala de tierra. Al final elegí Firebird y estoy, hasta el día de hoy, inmensamente contento con la elección. Se adapta como un guante a los requerimientos y jamás, pero jamás me ha dado problemas. Eso sí, no me atrevo a exponerlo a la internet. Sería relativamente rápido averiguar la clave de SYSDBA.

Nuevamente... estas volviendo a decir que FB es un juguete.
¡Pero claro, también dices que se moldea!

Vamos Chris... ¿al final es un juguete o un buen producto que sabe calzarse? Anda...

Empezado por Chris

Sí me encantaría ver mejoras en el motor de Firebird. En lo que respecta a la seguridad, procedimientos almacenados (siempre hay dónde mejorar) y optimización del uso de red (compresión y mayor tolerancia a errores son lo más importante). Al final, no tomes lo que he dicho como crítica a Firebird. Más bien tómalo como Features request que más que todo eso son.

Saludos,
Chris

Si claro, como si FB no soportara seguridad, ni procedimientos almacenados.

Empezado por mcs

Hola,
Me parece que, excepto Delphius, soys un poco "fanboys" de Firebird.

Gracias por el sarcasmo

Empezado por mcs

Y sabeis cual fue la primera limitación que encontre a Firebird, que los anteriores motores de bases de datos tienen? Los campos numericos autoincrementales. Será una tontería, pero para mi siempre será mucho más fácil definir un campo cómo "id INT NOT NULL AUTO_INCREMENT" que no definirlo cómo "id INT NOT NULL" y después crear un trigger para añadir el valor incremental...

Tengo entendido que en realidad el uso de los autoincrementales es lo peor que le ha pasado a la historia en las bases de datos. En el estándar SQL se recomienda fervientemente abandonar el concepto de autoincremental y empezar justamente a promocionar el uso de SEQUENCES (término que se impuso y aceptó como válido tras la última revisión allá por 2008) junto con TRIGGERS.

Empezado por mcs

Me olvidaba, la falta de campos del tipo BOOLEAN tambien es un poco molesto... :P

Pues si... en esto coincido. El problema con el BOOLEAN es que es un tipo de dato que ha llevado a unas cuantas discusiones en el estándar SQL. Si bien el estándar lo define, hay detractores que rechazan su puesta. Más que nada se debe a diferencias de opinión respecto a como tratar un BOOLEAN NULL y lo que implica realizar operaciones sobre éste; habiendo diferencias de opinión algunos sugieren que se evite su uso y en su lugar se utilice un "alias" numérico o cadena y dejar en manos del desarrollador de la base de datos como prefiere utilizarlos.

Saludos,