Oracle empieza a cerrar MYSQL

[[Chris]]

Empezado por Casimiro Notevi

¿Y qué aspectos debe mejorar?

Seguridad -el más importante-. Un mejor lenguaje para la programación de procedimientos almacenados. Reducir el uso de tráfico de red. Agregar más rutinas para el procesamiento de datos. Bueno, esos los que recuerdo por el momento. En cuanto valla recordando más los iré poniendo. Aunque reconozco que en las últimas dos versiones ha agregados cosas muy útiles, cómo por ejemplo poder administrar los usuarios con SQL y búsquedas de texto utilizando expresiones regulares.

Saludos,
Chris

[Casimiro Noteví]

¿Seguridad -el más importante-?
¿Un mejor lenguaje para la programación de procedimientos almacenados?
¿Reducir el uso de tráfico de red?
¿Agregar más rutinas para el procesamiento de datos?

¿Estamos hablando del mismo firebird?

[jhonny]

Chris, yo diría que en 2 o 3 de los aspectos que mencionas, según yo más bien son falencias pero de MySQL.

[Casimiro Noteví]

Empezado por jhonny

Chris, yo diría que en 2 o 3 de los aspectos que mencionas, según yo más bien son falencias pero de MySQL.

.

[[Chris]]

Empezado por jhonny

Chris, yo diría que en 2 o 3 de los aspectos que mencionas, según yo más bien son falencias pero de MySQL.

No entendí Cuáles aspectos Jhonny?

[jhonny]

Empezado por Chris

No entendí Cuáles aspectos Jhonny?

* Un mejor lenguaje para la programación de procedimientos almacenados.
* Agregar más rutinas para el procesamiento de datos.

Diría que esos dos, además de la lentitud en los procedimientos almacenados que comenta roman y que no me parece completamente libre, al ponerle tantas "trabas" a su licencia.

[roman]

Empezado por jhonny

* Agregar más rutinas para el procesamiento de datos.

¿A qué se refieren con esto? Porque si se refieren a funciones nativas me parece que no es para nada una carencia de mysql. Por el contrario, cuenta con muchas funciones que en firebird debes agregarlas mediante udfs.

// Saludos

[jhonny]

Empezado por roman

¿A qué se refieren con esto? Porque si se refieren a funciones nativas me parece que no es para nada una carencia de mysql. Por el contrario, cuenta con muchas funciones que en firebird debes agregarlas mediante udfs.

// Saludos

Bueno, Firebird hoy en día tiene muchas funciones nativas, que antes había que agregarlas por UDFs, pero que ya no... tendríamos que sacar un listado de las que tiene MySQl y determinar esto comparado realmente. Por otro lado y ya que lo mencionas, no se si... ¿MySQL tiene la posibilidad de agregarle más funciones, como lo hace Firebird con las UDFs o algo parecido?

[Rolando Glez]

Parece que los software open source que salen al mercado con mucho exito tiende a ser no mas que un anzuelo de clientes, pero la triste realidad del mercado hace que projectos tan noble como estos donde el lema es "uno para todos y todos para uno" como los tres mosqueteros se conviertan
en "YO les vendo a ustedes y todos me pagan a mi" (Empresa), asi que lo que empezó como algo noble se convirte en algo lucrativo, es decir el mismo producto pasa de una forma de projecto a otra es como si el open source fuera un beta tester del Software y una vez pasada la prueba entonces se realiza el cambio ,parece una buena estrategia de los desarroladores asi como de las compañias, pero a la larga pasará algo inevitable se pierden clientes, y lo considerarán como "daños coraterales" , open source es solo un SUEñO despierten a la realidad y cuando lo hagan se encontraran con una realidad llamada MERCADO

[Casimiro Noteví]

Amigo, disculpa si soy un poco tosco, pero NO TIENES NI IDEA de lo que hablas, infórmate antes, por favor.

[[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,

[[mightydragonlor]]

Pues compañeros, me parece que el tema se está poniendo muy tenso y espero que se bajen las ansias y escribamos en este hilo con mas cordura, yo soy un gran FanBoy de Firebird, en este momento FB 2.5 es demasiado bueno y puedo dar testimonio que para llevar la lógica de negocio al motos, no se necesita nada mas que el Standar SQL, la seguridad de Firebid aunque no es excelente, es muy buena, hace ya un mes, hice una prueba de fuerza bruta para el usuario SYSDBA, el programa se me quedaba colgado esperando respuesta, mientras los demás clientes seguían funcionando, lo de la clave de los usuarios es cierto, pero no es tanto problema de FB sino del tipo de hash aplicado, mismo problema que el de windows, sino estoy mal, se puede cambiar por el archivo de configuración de FB (no estoy seguro), pero de lo que si estoy seguo es que las bases de datos expuestas a internet son un fracaso por parte de los analistas que hacen esto, eso es un brutalidad, lo que se debe hacer es proporcionar una capa entre "internet" y "base de datos", por practicas tan tontas como estas es que han hackeado y robado información de muchas empresas multinacionales, que tienen sus servidores en oracle, mssql entre otros, también quiero dejar claro que FB no es un juguete comparado con ninguna otra base de datos, por el contrario, es un "pequeño" gigante que cada vez me llena de gratas sorpresas al usarlo.

[[Chris]]

Empezado por Delphius

No, no me caes mal... pero dejémoslo en que tienes la facilidad de exasperarme.

Yo creo que más bien es que no toleras una opinión contraria a la tuya. Te dejo esta prueba. Tú dices que para proyectos con una DB local y mono usuario (solo Windows) lo ideal sería Firebird Embeded. Bueno yo digo que es SQLite. ¿Discutimos?

Empezado por Delphius

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.

Nuca he jurado lealtad hacia ningún motor. Y si no criticara los problemas existente, quién lo haría entonces? Acaso no es buena la autocrítica? Crees que los problemas de seguridad se hubieran venido mejorando -aunque sea un poco- si alguién antes no hubiera hecho el llamado a mejorar las cosas?

Empezado por Delphius

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.

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

No quiero pensar que eres de los desarrolladores que para todo tipo de problemas tienen la misma solución. Tal vez digas que Firebird es adecuado para manejar las transacciones de Wall Street.

Empezado por Delphius

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.

Sé lo que cada uno tiene y que puedo pedirles.
A MySQL, búsquedas de texto completo (no disponibles en Firebird).
A Postgree, Estructuras de datos aptas para geolocalización (no disponibles en Firebird)
A SQLite, Simplicidad y ligereza (mucho mayor que Firebird Embeded).

Empezado por Delphius

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.

Necesitas leer el hilo y comprender en el contexto en que lo he dicho.

Empezado por Delphius

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?

Sí claro diez u once años. Pero súmale los casi veinte años que tenía Interbase cuando fue liberado. Allí ya no se hace tanta la diferencia.

Empezado por Delphius

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?

Porque es un excelente motor de base datos. Nunca he dicho lo contrario. Pero al César lo que es del César.

Empezado por Delphius

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é"

Entonces este señor Steve habrá diseñado ambos motores desde cero para que le des todos los méritos de lo que son hoy cada uno de ellos.

Creo que si haces una búsqueda en San Google, solo te encontrarás a tí sosteniendo que Firebird es inmensamente superior a Postgree. Por favor! Ambos tienen lo suyo y ambos son un excelentísimo producto. Pero a cómo te dije, al César lo que es del César.

Saludos,
Chris

[[Chris]]

Empezado por Casimiro Notevi

¿Seguridad -el más importante-?
¿Un mejor lenguaje para la programación de procedimientos almacenados?
¿Reducir el uso de tráfico de red?
¿Agregar más rutinas para el procesamiento de datos?

¿Estamos hablando del mismo firebird?

Sí Casimiro

Seguridad: Las contraseñas son de ocho caracteres en la práctica. No existe un método nativo para hacer conexiones por SSL. Usuarios a nivel de base de datos. Limitar los dominios sobre los que puede iniciar sesión. Comparado con las características de seguridad de Postgre, Firebird se queda como un juguete para niños.

Procedimientos almacenados: Nuevamente, comparado con Postgre, se queda como un juguete.

Uso de red: Sí, en comparación (nuevamente ) utiliza mucha banda. Además el protocolo es poco tolerante a errores de conexión, como la pérdida de datos o micro-cortes en la conexión.

Rutinas de Datos: Sí. Por ejemplo, no sé si existe aún una rutina para obtener el hast MD5 o SHA1 de un dato. Nuevamente, en comparación con Postgre se queda corto.

No es que quiera decir que Firebird debe ser Postgre. Dios no lo quiera. Para eso ya existe Postgre. Sino que todo esto te lo digo como argumento del por qué creo que Firebird está un poco atrás para poder competir con Postgre para captar esta estampida de desarrolladores.

Lo que sí me encantaría ver para la próxima versión de Firebird (3.0), es que se mejorará los aspectos de la seguridad y mejor tolerancia a errores de red. Eso para mí es lo más importante. Para el resto, sino necesitas de avanzados procedimientos almacenados y un millón de rutinas de datos, Firebird es una maravilla y me encanta. Desearía verlo más implementado en hosting y frameworks para desarrollo de aplicaciones .

Saludos,
Chris

[Casimiro Noteví]

Empezado por Chris

Sí, Casimiro

No estoy de acuerdo, pero aunque lo estuviese, ¿no estamos hablando de mysql?, ¿a qué viene comparar ahora con postgresql?

[[Chris]]

Empezado por Casimiro Notevi

No estoy de acuerdo, pero aunque lo estuviese, ¿no estamos hablando de mysql?, ¿a qué viene comparar ahora con postgresql?

En el sentido de que estoy argumentando el por qué creo que Postgre captará la gran mayoría de desarrolladores que migren de MySQL y nuestro Firebird no agarrará muchos caramelos de la piñata por ser el más pequeño tal vez o por carecer de algunas funcionalidades con respecto a Postgre.

Saludos,
Chris

[ASAPLTDA]

Empezado por Chris

Seguridad -el más importante-. Un mejor lenguaje para la programación de procedimientos almacenados. Reducir el uso de tráfico de red. Agregar más rutinas para el procesamiento de datos. Bueno, esos los que recuerdo por el momento. En cuanto valla recordando más los iré poniendo. Aunque reconozco que en las últimas dos versiones ha agregados cosas muy útiles, cómo por ejemplo poder administrar los usuarios con SQL y búsquedas de texto utilizando expresiones regulares.
Saludos,
Chris

La faltan funciones, definir campos tipo %row para evitar definiciones de declare , le falta us sistema de gestion de procesos (jobscheduler), la faltan rutinas entre procesimientos o paso de valores tipo %row, integridad de datos cuando se adicionan restricciones a nivel de la base de datos
y .... me encanta firebird por su facilidad de cambiar algunas cosas, facilidad de transportar la base de datos, estabilidad

[[Delphius]]

Empezado por Chris

Seguridad -el más importante-.

Bueno, si.. es un pedido que se viene haciendo pero si fuera por vos Chris entonces quedate con tu queridito PostgreSQL. ¡Vaya si algunos a algunos les encanta seguir tirando leña sobre este tema! Ya dijeron que para FB 3.0 habrán mejorado e implementado mejoras en este aspecto. ¿No te podés aguantar un poquito?
Si en verdad Firebird fuera tan insegura... ¿Porqué se sigue utilizando? Ponete a leer los casos de éxito que está publicando FB y te darás cuenta de que en muchos aspectos se prefiere FB por incluso a Oracle.

Empezado por Chris

Seguridad -el más importante-.
Un mejor lenguaje para la programación de procedimientos almacenados.

¿Mejor? ¡Otra vez la burra al trigo! De entre varios motores, el que mejor está poniendo ganas es FB. Ha... por cierto, desde 2.5 se ha estandarizado y según tengo entendido viene con una especie de herramienta, un debugger, o algo por el estilo.

Empezado por Chris

Reducir el uso de tráfico de red.

¿Se me permite reir?... ¡Por Dios! Si hay algo que enorgullecerse del buen equipo de FB es que con cada liberación se mejora entre un 33% a 50% respecto a la anterior en la eficiencia en el uso y tráfico de red.

Empezado por Chris

Agregar más rutinas para el procesamiento de datos.

Desde FB 2.x FB cuenta con un amplio abanico, y además uno puede extenderse gracias a UDF. ¿Te parece que son pocas?
¿Y cuáles más? ¿Cuáles crees que debería tener para ser superior, y estar en lo más top de lo top?

Empezado por Chris

Sí Casimiro
Seguridad: Las contraseñas son de ocho caracteres en la práctica. No existe un método nativo para hacer conexiones por SSL. Usuarios a nivel de base de datos. Limitar los dominios sobre los que puede iniciar sesión. Comparado con las características de seguridad de Postgre, Firebird se queda como un juguete para niños.

Bueno, sigue con tu juguete de PostgreSQL que es más pesado que un elefante . Nosotros seguiremos con FB.... ¡que es tan liviano que vuela!

Empezado por Chris

Procedimientos almacenados: Nuevamente, comparado con Postgre, se queda como un juguete.

Dime... ¿cómo es que los comparas? Danos más info sobre eso. Si me explicas quizá puedas entender a lo que apuntas.

Empezado por Chris

Uso de red: Sí, en comparación (nuevamente ) utiliza mucha banda. Además el protocolo es poco tolerante a errores de conexión, como la pérdida de datos o micro-cortes en la conexión.

¿Utiliza mucha banda? Mira vos... ¿No había dicho antes que en cada liberación se mejora? A ver... si ya lo dije. ¿Poco tolerante? ¡De donde sacas semejante cosa!

Empezado por Chris

Rutinas de Datos: Sí. Por ejemplo, no sé si existe aún una rutina para obtener el hast MD5 o SHA1 de un dato. Nuevamente, en comparación con Postgre se queda corto.

A ver muchacho... FB es un motor de base de datos... No se porqué, o de donde nace la manía y la locura por convertir a un motor de base de datos en un lenguaje de programación más. ¡Dejémonos de joder!
Un motor es un motor... ¿Para que meterle más, y más.... rutinas, funciones? ¿TODAS te hacen falta?

Seamos más equilibrados, lo que hace bien el motor déjaselo a el, para el resto está Mastercard; este... el Lenguaje de programación X y la aplicación que uno le desarrolle. No le pidas a un motor de base de datos que tenga incorporada una biblioteca para trabajar con redes neuronales, caso extremis.

Empezado por Chris

No es que quiera decir que Firebird debe ser Postgre. Dios no lo quiera. Para eso ya existe Postgre. Sino que todo esto te lo digo como argumento del por qué creo que Firebird está un poco atrás para poder competir con Postgre para captar esta estampida de desarrolladores.

Lo bueno es que hay gente de PostgreSQL que le debe mucho favor a FB, como también una buena cantidad de gente de MySQL.
Y que mejor saber que los avances del proyecto PostgreSQL se están amesetando y FB viene ganando más adeptos.
No hace falta que la gente de MySQL se venga; ya se está viniendo la gente de PostgreSQL que reconoce que tienen un elefante pesado y no saben como seguir avanzando sin darle de comer más.

Empezado por Chris

Desearía verlo más implementado en hosting.
Chris

Bueno, eso si te lo permito. Allí si te doy muchísima más razón. Le falta penetración en ese mercado.

Saludos,

[[Chris]]

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

Hombre, no sugiriendo que uno sea mejor que el otro. 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. Por eso uno tiene que saber que tiene uno y que le falta al otro. 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.

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.

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

PD.: Si deseas crear una aplicación de tres capas, pero utilizando la arquitectura Cliente <-> Servidor (DB exclusivamente), debes utilizar procedimientos almacenados para la lógica de negocios. Para escribir la lógica es de gran ayuda tener un cuasi lenguaje de programación. Es ahí dónde es bueno que una base de datos disponga de buen soporte de procedimientos almacenados (en Postgre se usa Python).

[mcs]

Hola,

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

Firebird es una buena base de datos, pero para nada es la octava maravilla del mundo. Tiene limitaciones, tiene "problemas" (lo comentado por Delphius del consumo de ancho de banda o todo el tema seguridad), y estas cosas están aquí, y no lo podemos ignorar. Es más, al reconocer que hay estos problemas, se ayuda a mejorar el sistema evitándolos, ya sea con "workarounds" (por ejemplo el uso del Zedebee para comprimir ancho de banda y encriptar la conexión), o bien pidiendo a los desarrolladores que se solucionen estos inconvenientes.

Yo hace relativamente poco que uso Firebird, un poco más de un año y medio. Antes había usado HypersonicDB (Java), MySQL y MS Access. 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...