Oracle empieza a cerrar MYSQL

[rretamar]

El futuro del proyecto MySQL: Open-Core

http://www.kabytes.com/wp-content/uploads/2010/03/mysql-nosql.jpg

Recientemente Oracle anuncio algo (http://blogs.oracle.com/MySQL/entry/new_commercial_extensions_for_mysql) que ya muchos veníamos temiendo, el proyecto MySQL deja de ser un proyecto totalmente de software libre, una noticia que se oficializa y que ya venia haciendo ruido entre los desarrolladores desde la compra realizada por Sun (http://www.kabytes.com/actualidad/sun-compra-mysql/). Este sutil, pero fundamental cambio impuesto por Sun, cambia por completo el modelo de negocio original que eligió el creador de MySQL, en donde el código fuente estaba liberado totalmente y disponible para que la comunidad pudiera realizar modificaciones, e inclusive mejoras. Ahora muchas de las extensiones más avanzadas y útiles de MySQL Enterprise Edition van a ser comerciales, recientemente se incorporaron tres nuevas, pueden leer las características de las mismas en el blog oficial de Oracle (http://blogs.oracle.com/MySQL/entry/new_commercial_extensions_for_mysql).


El nuevo modelo de negocios de MySQL pasa a ser Open-Core. Este modelo consiste en brindar un núcleo abierto y vender extensiones que son 100% privativas.


El modelo en sí no es del todo malo, salvo por un detalle, en general este tipo de licenciamientos terminan provocando un núcleo muy poco útil y que requiere prácticamente de forma obligatoriamente extensiones, que por lógica pura, son de acceso privado y por medio de un pago.
Este tipo de extensiones privativas tienen una serie de desventajas enormes, como comenta Michael Widenius (http://monty-says.blogspot.com/2011/09/oracle-adding-close-source-extensions.html) (creador de MySQL, ahora trabajando en María DB):
El licenciamiento Open Core no tiene nada que ver con un proyecto de código abierto.
No se pueden corregir errores, y no se puede contratar a nadie para hacerlo, salvo al proveedor original.
No se puede examinar y mejorar el producto.
No se puede utilizar cualquier extensión abierta o comercial de cualquier otra persona.
Uno se encuentra limitado a las plataformas que los vendedores originales ponen a nuestra disposición.El panorama para MySQL no es bueno, a medida que pasan los meses las teorías de que el proyecto no esta bien encaminado se vuelven realidad. No obstante no hay que preocuparse demasiado, MariaDB esta cobrando más y más fuerza, por lo que creo que será el reemplazo obligatorio y lógico.

Enlace original del artículo:
http://www.kabytes.com/actualidad/el-futuro-del-proyecto-mysql-open-core/

[MAXIUM]

Lo predije, Oracle comprando jugadores del equipo contrario para no meter goles.

¿Que hacer?, ¿le saldrá el tiro por la culata como le sucedió a OpenOffice vs Libre Office?

[Al González]

Interesante enlace rretamar (y gracias por la transcripción), era algo hasta cierto punto previsible.

Creo que de esto surge una buena oportunidad para Firebird, pues muchos usuarios de MySQL se estarán preguntando a qué base de datos libre moverse ahora. Cierto, son varias las opciones, pero la mejor amiga de Delphi cada vez está mejor.

Por otra parte, veo en MySQL un camino muy similar al de PHP: su momento cumbre ha quedado atrás. Y así como muchos ex-PHP han adoptado alternativas modernas como Python, Ruby, etc., creo que ocurrirá algo similar con su inseparable compañero de toda la vida, MySQL.

Un abrazo open-change.

Al González. :)

[D-MO]

...como le sucedió a OpenOffice vs Libre Office?
Exacto, MaríaDB (http://mariadb.org/) terminará reemplazándolo

...Y así como muchos ex-PHP han adoptado alternativas modernas como Python, Ruby, etc., c...
¿Que comes que adivinas?... :p

En efecto, los hasta ahora usuarios de MySQL terminarán adoptando un nuevo motor de bases de datos aunque me atrevo a decir que quienes tomarán la decisión por los usuarios serán los proveedores de hospedaje web. ¿Quién quiere apostar :D?

Es una pena que Oracle realice estas acciones con los proyectos abiertos de Sun, demuestra que su interés es únicamente comercial.


Lo hizo con OpenSolaris
Intentó hacerlo con OpenOffice
Ahora es My SQL
¿Seguirá con Java?


Saludos.

[roman]

un camino muy similar al de PHP: su momento cumbre ha quedado atrás. Y así como muchos ex-PHP han adoptado alternativas modernas como Python, Ruby, etc.


¡Ah caray! Y esto ¿de dónde lo concluyes?

// Saludos

[Julián]

¡Ah caray! Y esto ¿de dónde lo concluyes?

// Saludos


Eso me pregunto yo :D.

[Casimiro Notevi]

¡huy, huy, huy...!, que se han picado los phperos (qué feo suena) :D

[jlrbotella]

Despues vendrá Java.

Lo mismo pasará a largo plazo con PHP. (IBM)

En definitiva al principio todo es libre y al final todo acaba siendo de pago, el porque, a los programadores, ingenieros, etc.. hay que pagarles y hoy por hoy con la crisis que hay no existen fondos para subvencionar los proyectos.

Al menos con Delphi ya sabemos lo que tenemos que pagar y no llevarnos sorpresas.

Un saludo,
JL

[Casimiro Notevi]

Lo mismo pasará a largo plazo con PHP. (IBM)
¿IBM?, PHP no tiene nada que ver con IBM, salvo que su creador estuvo trabajando allí.

En definitiva al principio todo es libre y al final todo acaba siendo de pago
Bueno, eso no es así, lo que es libre, es libre y no se puede cambiar (dependiendo de la licencia que tenga). Pongo el ejemplo de Interbase, usaron una licencia libre con su interbase 6.0 y de ella surgió otro proyecto: firebird.
Luego los de Borland (dueños de interbase) volvieron a cambiar no liberar la versión siguiente de interbase, pero la versión 6 tuvo que seguir siendo libre, tal y como fuerza por ley su licencia.
Así que mysql (que es de lo que se habla, no de php) seguirá siendo libre lo que ahora mismo es libre.

[Al González]

¡huy, huy, huy...!, que se han picado los phperos (qué feo suena) :D
Perdón, me refería a Delphi. ¡Chanfle! Quise decir C++, ¡ah no! COBOL, digo Clipper, ¡no!...este...¿cuál es el que menos seguidores tiene? :o :D

[D-MO]

Perdón, me refería a Delphi. ¡Chanfle! Quise decir C++, ¡ah no! COBOL, digo Clipper, ¡no!...este...¿cuál es el que menos seguidores tiene? :o :D

¿Brainfuck (http://es.wikipedia.org/wiki/Brainfuck)?:eek:

[mightydragonlor]

El futuro de Java ya está marcado, "sino compras oracle no podras usar java", algo así han de querer hacer los de oracle xD

[Delfino]

Eso animara a los de MySQL convertirse a una BD mejor: Firebird..

[Chris]

No creo que Firebird logre captar un porcentaje considerable de esta estampida de desarrolladores cambiando de motor. Más bien creo que el mayor porcentaje se lo llevará PostgreSQL y motores No-SQL que se están volviendo moda últimamente (por si tu aplicación es el próximo Facebook o Twitter).

Firebird necesitará mejorar en varios aspectos para poder captar a estos desarrolladores. Lamentablemente, creo que no podrá lograrlo por el corto tiempo del que se dispone.

Seguramente son los desarrollares de MariaDB los que se han encargado de hacerle eco a la noticia -a ellos les conviene-. No olvidemos que MySQL jamás ha sido completamente libre, a menos que lo utilizarás para propósitos OpenSource, que no era la mayoría de los casos. Por último, no hay mal que por bien no venga y me alegra escuchar esta noticia porque MySQL no me agrada por esa licencia dual que siempre ha tenido.

Saludos,
Chris

[Casimiro Notevi]

Firebird necesitará mejorar en varios aspectos para poder captar a estos desarrolladores. Lamentablemente, creo que no podrá lograrlo por el corto tiempo del que se dispone.

¿Y qué aspectos debe mejorar?

[roman]

Firebird necesitará mejorar en varios aspectos para poder captar a estos desarrolladores. Lamentablemente, creo que no podrá lograrlo por el corto tiempo del que se dispone.


Tampoco creo que la gente que usa mysql migre a firebird, pero, igual que Casimiro, me gustaría saber cuáles son estos aspectos que consideras debe mejorar. Así mismo, me gustaría que Delfino nos comentara en qué sentido le parece mejor firebird que mysql. Entendámonos, para lo que suele usarse mysql, no me parece que le falte algo que sí tenga Firebird (bueno, sí, los procedimientos almacenados de mysql son insufriblemente lentos).


y motores No-SQL que se están volviendo moda últimamente


Yo no termino de entender esto del nosql. Estuve viendo algo de mongodb y se ve muy interesante pero, ¿hasta que punto es usable si en sistemas de gestión suelen ser imprescindibles las transacciones, que no soporta nosql?


Seguramente son los desarrollares de MariaDB los que se han encargado de hacerle eco a la noticia -a ellos les conviene-.


Y, ¿realmente tendrá futuro MariaDB? Digo, dicen que segundas partes nunca son buenas. Además, quién nos asegura que Widenius no se deshará de ella igual que con mysql, ¿o no fue así?

// Saludos

[Chris]

¿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 Notevi]

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

¿Estamos hablando del mismo firebird? :confused::confused::confused::confused::confused::confused:

[Chris]

Yo no termino de entender esto del nosql. Estuve viendo algo de mongodb y se ve muy interesante pero, ¿hasta que punto es usable si en sistemas de gestión suelen ser imprescindibles las transacciones, que no soporta nosql?


En sistemas donde la atomicidad de datos es presindible y el almacenamiento y lectura sea masivo. Por ejemplo un Tweet o un mensaje de facebook. Pero tengo entendido que algunos de estos motores sí soportan transacciones en un nivel básico. Por ejemplo BigTable soporta transacciones que se limiten a la modificación de una sola tabla.


Y, ¿realmente tendrá futuro MariaDB? Digo, dicen que segundas partes nunca son buenas. Además, quién nos asegura que Widenius no se deshará de ella igual que con mysql, ¿o no fue así?

MySQL fue vendida por mil millones de dólares a Sun. Con cuánto se esa cantidad se habrá quedado este chico? No sería de extrañarse que él tenga una estrategia para volver hacer lo mismo con MariaDB. Por otro lado, no conozco exactamente la licencia con la que se distribuye este motor, pero supongo que deben ser igual o muy similar a la que usó con MySQL. Por lo que si quieres utilizarla para propósitos closed-source, tendrás que pasar por caja.

Saludos,
Chris

[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 Notevi]

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.

http://www.clubdelphi.com/foros/images/icons/icon14.gif



.

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

¿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 :D) 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

[Chris]

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í :p Cuáles aspectos Jhonny?

[jhonny]

No entendí :p 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.

[Casimiro Notevi]

Sí, Casimiro :)

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

[Chris]

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

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

[roman]

* 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]

¿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?

[roman]

No lo creo, y si lo tiene debe ser desastroso, igual que los procedimientos almacenados.

// Saludos

[ASAPLTDA]

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]

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.

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.


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.


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?

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 :rolleyes: . Nosotros seguiremos con FB.... ¡que es tan liviano que vuela!


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.


Uso de red: Sí, en comparación (nuevamente :D) 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!


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. ;)


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. :D


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...

[mcs]

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

[Casimiro Notevi]

Para empezar, me gusta muchísimo PostgreSql y Firebird, y no tanto MySql.
El haber elegido usar firebird es porque por aquellos días había un grave problema con postgresql, era muy lento. Lo demás me encantaba, la verdad.
Pero las pruebas que hice, estoy hablando de 1998/99 (no existía firebird, era interbase), resultaron abrumadoramente superior la velocidad de interbase sobre postgresql.
Otro punto a favor de interbase (entre otros muchos) es que puedes desconectar el servidor (de la corriente eléctrica), o puedes resetear el equipo, y 'normalmente' nunca pasa nada, se recupera automáticamente como si no hubiese pasado nada. Resumiendo es rápido y seguro ante problemas físicos.
Yo sé que postgresql es muy potente, que tiene características muy interesantes, no lo descarto para futuros proyectos, pero centrándonos en lo que trata este tema: mysql.
Si tuviera que elegir entre mysql y firebird para lo que se usa hoy en día mysql (en la mayoría de casos), me parece mucho más acertado usar firebird, es mucho más pequeño, no consumo apenas recursos, es muy rápido, es muy seguro ante caídas/parones/desconexiones, etc.

Fuera de internet, sin embargo, postgresql lo usaría para proyectos de gestión para empresas rivalizando también con firebird.
Por ahí tengo una comparativa que hicieron hace años entre mysql, interbase, postresql y sapdb. Una de las pruebas que hicieron (además de las habituales de insertar muchos registros y haces cosas), fue la de conexiones persistentes y.... ya lo encontré, mejor pongo los enlaces al final de este texto.
Ahí dicen frases como:
* Mysql bajo pocas conexiones funcionó perfectamente, cumpliendo expectativas, pero no pudo con el Interbase en el tramo final.
* Interbase se lleva el premio de base de datos ideal para servidor Internet.

Hay que tener en cuenta que es de hace bastantes años, que todos han envolucionado, pero sirve de referencia para darnos cuenta que muchas veces son sensaciones, prejuicios, imagen, desconocimiento, etc. y lo que tenemos en nuestro cerebrito no siempre es la realidad de las cosas.
La máquina de test es un Pentium III 800Mhz con 256Mb RAM y un disco IDE de 20Gb. (ya hace tiempo, sí)

Aquí algunos datos que se ofrecen en la comparativa:

Segundos en completar las 1000 peticiones
MySQL PostgreSQL Interbase SAP DB
10p 312,66 752,74 225,30 305,31
10 325,22 943,40 212,42 300,03
20p 849,47 813,69 262,76 549,99
20 947,91 974,51 291,12 612,06
30p 1153,88 1620,00 377,75 763,76
30 1199,01 1468,79 408,23 806,18
40p Timeout Error 681,38 timeout
40 Timeout Error 683,29 timeout
50p Timeout Error timeout timeout
50 Timeout Error timeout timeout


Peticiones servidas por segundo
MySQL PostgreSQL Interbase SAP DB
10p 3,17 1,32 4,39 3,24
10 3,04 1,04 4,66 3,30
20p 1,17 1,21 3,77 1,80
20 1,04 1,01 3,40 1,62
30p 0,86 0,61 2,62 1,30
30 0,83 0,67 2,43 1,23
40p Timeout Error 1,45 timeout
40 Timeout Error 1,45 timeout
50p Timeout Error Timeout timeout
50 Timeout Error Timeout timeout
Ratio de transferencia en Kb/seg
MySQL PostgreSQL Interbase SAP DB
10p 763,40 317,09 1059,45 781,79
10 733,98 253,01 1208,55 795,54
20p 280,97 293,34 962,69 433,98
20 251,80 244,93 940,92 389,97
30p 206,85 147,34 664,13 312,52
30 199,07 162,50 658,69 296,07
40p Timeout Error 363,22 timeout
40 Timeout Error 402,41 timeout
50p Timeout Error timeout timeout
50 Timeout Error timeout timeout


Aquí (http://www.intitec.com/varios/ComparativaSQL.pdf) está el enlace.

[ASAPLTDA]

Hola,

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

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...

Uso ibexpert, y lo que hice fue definir una tabla que llamo aaaa la cual tiene asociado un trigger, que ya manaja el autoincrmento y los 5 campos comnes en cada tabla, le dijo que la replique y ya tengo el esqueletro de la tabla , solo me toca decirle duplique tabla y fin del problema.

Pero de las cosas que me gustaria tener en firebird seria por ejemplo los campos tipo %row, ejemplo mi archivo de clientes aunque no uso todos los campos prefiero decir
campos %row
select * from clientes into w_row_clientes en ves de :
select codigo,nombre,direccion.... from clientes into :w_codigo, :w_nombre ............
por eso me daria facilidad de desarrollo de funciones/procedimientos enla base de datos
funciones
select cliente, f_get_nombrecliente(cliente) from mov_CXC where ....
Manejo de selects tipo bases cubos de datos, aunque por ahi hay un ejemplo que lo hace
select cliente,sum(ventas),mes from ventas, agrupado por cliente,(matriz(mes))
y el resultado fuera
cliente,ventas_mes01. ventas_mes02...

ahora muchas veces en la busqueda de una verdad inalcansable uno quiere que los procesos se hagan en la base de datos, otras veces se hagan en una capa intermedia,
uno quiere que se haga con un lenguajes externo a la base de datos o un lenguaje interno a la base de datos
creo de pronto como recomendo la ibm (as400) haga los procesos en la base de datos no la haga en los programas aunque la la base de datos de ibm maneja procedures/functions en lenguaje PLSQL o en lenguje externos RPG/COBOL/JAVA/...? hace muchos anos no los manejamos

[Casimiro Notevi]

Todas tienen cosas interesantes, característica que nos gustaría tener en las demás, realmente todas son magníficas.

¿Qué es eso de los campos %row?, ¿una especie de variable?

Por cierto, aquí (http://www.intitec.com/varios/bmsql-postgres-sqlsrvr-v1.0-1.pdf) hay una buena comparativa entre postgresql y ms sql server, la hizo hace no mucho los de RedHat, usaron equipos bien potentes. Adivinad quién salió ganando la comparativa.


Hardware:
Database: 2 x HP ProLiant DL370 G6
Dual Socket, Quad Core (Total of 8 cores)
Intel® Xeon® CPU W5580 @ 3.20GHz
48 GB RAM
Driver: 1 x HP ProLiant DL580 G5
Quad Socket, Quad Core (Total of 16 cores)
Intel® Xeon® CPU X7350 @ 2.93GHz
64 GB RAM

Software:
Linux: Red Hat Enterprise Linux 5.4 (2.6.18-164.el5)
Database: Postgres Plus 8.3.8

Windows: Windows Server 2008 R2 Enterprise
Database: SQL Server 2008 R2

[roman]

Eso sí, no me atrevo a exponerlo a la internet. Sería relativamente rápido averiguar la clave de SYSDBA.


Pero, ¿qué quiere decir esto? ¿Estás diciendo que firebird no sirve para internet? ¿Cómo se accede entonces remotamente? ¿Qué no puede cambiarse el usuario y contraseña?


Si tuviera que elegir entre mysql y firebird para lo que se usa hoy en día mysql (en la mayoría de casos), me parece mucho más acertado usar firebird, es mucho más pequeño, no consumo apenas recursos, es muy rápido, es muy seguro ante caídas/parones/desconexiones, etc.

Jamás he tenido un problema de seguridad con MySQL y, si vamos a eso, ni siquiera de velocidad ni tampoco de pérdida de datos por desconexiones, etc.

Si a veces la gente se fija una idea...

// Saludos

[Chris]

Pero, ¿qué quiere decir esto? ¿Estás diciendo que firebird no sirve para internet? ¿Cómo se accede entonces remotamente? ¿Qué no puede cambiarse el usuario y contraseña?

Si sirve, pero no es seguro. Haz una suposición: la contraseña de SYSDBA lo más probable es que tenga de 6 a 8 caracteres. Cuánto tomaría, en un ataque de fuerza bruta averiguar la contraseña? relativamente poco si tomamos en cuenta que la longitud máxima de una contraseña es 8 carácteres.

Saludos,
Chris

[mcs]

Si sirve, pero no es seguro. Haz una suposición: la contraseña de SYSDBA lo más probable es que tenga de 6 a 8 caracteres. Cuánto tomaría, en un ataque de fuerza bruta averiguar la contraseña? relativamente poco si tomamos en cuenta que la longitud máxima de una contraseña es 8 carácteres.

Saludos,
Chris

Estás seguro de esto? :eek: Sólo 8 carácteres?? :eek: No hay ninguna forma de poner contraseñas más largas?

[Casimiro Notevi]

Si tuviera que elegir entre mysql y firebird para lo que se usa hoy en día mysql (en la mayoría de casos),
Me equivoqué, quise decir:
Si desapareciera mysql y tuviera que elegir entre postgresql y firebird para lo que se usa hoy en día mysql (en la mayoría de casos),... usaría firebird.

Si a veces la gente se fija una idea...
Cierto :):o

[Casimiro Notevi]

The v.2.0 Superserver has active protection to make a brute-force attack more difficult. After a few failed attempts to log in, the user and IP address are locked for a few seconds, denying any attempt to log in with that particular user name OR from that particular IP address for a brief period.
No setup or configuration is required for this feature. It is active automatically as soon as the Firebird 2.0 Superserver starts up.



New security database

The new security database is renamed as security2.fdb. Inside, the user authentication table (http://ibexpert.net/ibe/index.php?n=Doc.Table), where user names and passwords are stored, is now called RDB$USERS. There is no longer a table named "users" but a new view (http://ibexpert.net/ibe/index.php?n=Doc.View) over RDB$USERS that is named "USERS". Through this view, users can change their passwords.
For details of the new database, see New security database (http://ibexpert.net/ibe/index.php?n=Doc.SecurityInFirebird2#TheNewSecurity) in the section about authentication (http://ibexpert.net/ibe/index.php?n=Doc.SecurityInFirebird2#Authentication) later in this chapter.
For instructions on updating previous security databases, refer to the section Dealing with the new security database (http://ibexpert.net/ibe/index.php?n=Doc.SecurityInFirebird2#DealingWithThe) at the end of this chapter.
Better password encryption

A. Peshkov
Password encryption/decryption now uses a more secure password hash (http://ibexpert.net/ibe/index.php?n=Doc.Hashing) calculation algorithm.
Users can modify their own passwords

A. Peshkov
The SYSDBA remains the keeper of the security database. However, users can now modify their own passwords.
Non-server access to security database is rejected

A. Peshkov
gsec (http://ibexpert.net/ibe/index.php?n=Doc.FirebirdAndInterBaseCommandLineUtilities#GSEC) now uses the Services API (http://ibexpert.net/ibe/index.php?n=Doc.API). The server will refuse any access to security2.fdb except through the Services Manager.
Active protection from brute-force attack

A. Peshkov
Attempts to get access to the server using brute-force techniques on accounts and passwords are now detected and locked out.

Login with password is required from any remote client.
Clients making too many wrong login attempts are blocked from further attempts for a period.Support for brute-force attack protection has been included in both the attachment functions of the Firebird API and the Services API. For more details, see Protection from brute-force hacking (http://ibexpert.net/ibe/index.php?n=Doc.SecurityInFirebird2#ProtectionFromBrute).

[Chris]

Estás seguro de esto? :eek: Sólo 8 carácteres?? :eek: No hay ninguna forma de poner contraseñas más largas?

Así es en la practica. Tu puedes asignarle a un usuario una contraseñas de hasta 64 caracteres, creo. Pero Firebird solo utiliza los primeros 8 caracteres e ignora el resto. Esto no forma parte del diseño de Firebird, sino es un bug que se descubrió relativamente hace poco. Todas las versiones están afectadas, inclusive la última. El equipo de Firebird está desde trabajando en la solución, pero ya llevan casi dos años trabajando en ella. Se han tardado tanto porque no quieren romper la retrocompatibilidad.

Saludos!

[roman]

Pero, entonces: ¿firebird no permite limitar el acceso según la dirección ip? Con MySQL, por ejemplo, jamás se da acceso a root o cualquier otro usuario con privilegios amplios como no sea desde local. :confused:

// Saludos

[roman]

Así es en la practica. Tu puedes asignarle a un usuario una contraseñas de hasta 64 caracteres, creo. Pero Firebird solo utiliza los primeros 8 caracteres e ignora el resto. Esto no forma parte del diseño de Firebird, sino es un bug que se descubrió relativamente hace poco. Todas las versiones están afectadas, inclusive la última. El equipo de Firebird está desde trabajando en la solución, pero ya llevan casi dos años trabajando en ella. Se han tardado tanto porque no quieren romper la retrocompatibilidad.

Saludos!

¡Ah! Caray. Disculpa pero esto me es difícil de creer. Es decir, sí puedo creer que exista tal bug, pero ni de relajo puedo creer ni que sea difícil de solucionar ni mucho menos que la razón sea por retrocompatibilidad.

// Saludos

[RONPABLO]

Hola,

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...

Si es algo que causa un poco de "estrés" cuando uno viene de otro motor, pero ya me he adaptado y pues si, a mi me pueden meter en el saco de los fanboys de firebird, creo que son más las cosas buenas que encontré en firebird que en MySQL, empezando por su licencia que siempre ha sido clara mientras que con MySQL da oportunidad de confusión con su licencia dual (y que ahora con Oracle no noto la diferencia con la anterior), ya luego cuando descubrí los procedimientos almacenados y los disparadores ni hablar, en ese momento MySQL no los tenía (y por los comentarios que he ledio ahora no son la gran cosa) y mucho menos Access o Paradox (que eran mis otras opciones de trabajo), el consumo de recursos de firebird me iba muy bien en equipos viejos mientras que instalar un MySQL en un windows 98 con un procesador malo era condenar el equipo a demorarse a arrancar 5 o 6 minutos despues de lo normal y estar expuesto a múltiples bloqueos (y yo tenía y tengo clientes con equipos de de 10 o más años con un solo computador donde hacen todo y tengo clientes con una red de trabajo "grande" con un servidor dedicado montado en un verdadero servidor).

[Casimiro Notevi]

Que yo sepa, la longitud del password no es ningún bug que no hayan querido solucionar, lo hicieron así en su día (interbase de borland) y así ha quedado.
He buscado en los bugs y no lo he encontrado, puede que no lo haya visto.

Which characters can be used for user password in Firebird?


The only limitation for Firebird password is length of maximum 8 characters. Those can be any characters, i.e. any sequence of bytes (0-255), zero might be hard to insert. You should check your connectivity library (access method) for what is supports, since some tools allow you to put some characters in password, but won't let you log in with that password later. If you decide to play with that, better use some non-SYSDBA account for testing, so that you can always reset the password. If you manage to damage SYSDBA password, read FAQ #55 (http://www.firebirdfaq.org/faq55).

http://www.firebirdfaq.org/cat7/

[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 Notevi]

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

[Delphius]

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. :D
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.


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.


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.


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?


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


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...


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. :rolleyes:

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

Gracias por el sarcasmo :D :p


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.

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]

No, no me caes mal... pero dejémoslo en que tienes la facilidad de exasperarme. :D
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? :cool:


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?


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. :D


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).


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.


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.


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.


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

[Casimiro Notevi]

Sigamos la "guerra" :D
Tal vez digas que Firebird es adecuado para manejar las transacciones de Wall Street.
¿Cuáles son los requisitos necesarios?, me gustaría saberlo para poder convencerme.

A MySQL, búsquedas de texto completo (no disponibles en Firebird).
¿Texto completo?, ¿qué quieres decir con eso?, me pones un ejemplo, por favor.

A Postgree, Estructuras de datos aptas para geolocalización (no disponibles en Firebird)
Cierto, postgresql lo permite.

[Casimiro Notevi]

Y ahora me toca disparar, jejeje :)
Puestos a hablar de "lo malo" que es uno u otro, me he encontrado información que confirma que postgresql es muy malo :D

He leído que no existe una versión de postgresql "incrustable", "embebida" o como se le llame. De firebird, sí :)
También he leído, no sé si las últimas versiones lo tienen, que no existen campos calculados en postgresql. En firebird, sí :) Ejemplo:

CREATE TABLE ejemplo (
id integer not null,
campo1 currency not null default 0,
campo2 currency not null default 0,
total computed by (campo1 + campo2),
primary key (id)
);

Sólo he buscado un poquito, pero seguro que si busco más, encontraré más "fallos" de postgresql :D

[Casimiro Notevi]

Más cosas, he buscado y no lo he encontrado, pero hay algo en firebird que está muy interesante y no sé si lo tiene postgresql:
Los triggers, además de los habituales before/after insert/update/delete también pueden ser creados de una vez para varios eventos, ejemplo:

create trigger t_ejemplo_ active
BEFORE INSERT OR UPDATE OR DELETE POSITION 0
as
begin
if INSERTING then
loquesea

if UPDATING then
loquesea

if DELETING then
loquesea

end


Pero además hay más, a veces es necesario hacer varias cosas distintas en un mismo evento de trigger, o cosas totalmente distintas, o unas cosas antes que otras, pues bien, se puede tener varios triggers, por ejemplo, before insert, se diferencian por la 'position'.
Ejemplos:
create trigger t_ejemplo_ active
before insert POSITION 0

create trigger t_ejemplo_ active
before insert POSITION 1

create trigger t_ejemplo_ active
before insert POSITION 2

¿Tiene esa funcionalidad postgresql?

[mightydragonlor]

Empezado por Chris
A MySQL, búsquedas de texto completo (no disponibles en Firebird).
La búsqueda de texto completo en FB si son posible, no por que ya exista una función para ellos, pero si creas una serie de procedimientos almacenados podrás tener esa utilidad, Aquí (http://www.ibphoenix.com/downloads/FirebirdConf2006/TECH-TPZ303-R/TECH-TPZ303-R.zip)los scripts y la explicación, también puedes usar una de estas (http://www.firebirdfaq.org/faq328/)opciones.

[Delfino]

Hace un año y medio buscando por Google la palabra Firebird me salian 9 millones de resultados aprox. Para Postgresql me salian mas 10 millones de resultados.

Ahora salen 40 millones para Firebird y 35 millones para Postgresql.

Hay una campaña de los patrocinadores de Firebird llamada MindTheBird que seguro esta dando muy buenos resultados.

N.B en todas las comparativas que he leido entre las dos BDs sale ganando Firebird a Postgresql en velocidad. No sera casualidad.

[Al González]

Recuerdo cuando era joven y discutía con la misma energía que ustedes. ;)

[LIST]
He leído que no existe una versión de postgresql "incrustable", "embebida" o como se le llame [...]
Incrustrada. :)

Lo que puedo sacar en resumen es que las tres bases de datos más mencionadas en este hilo son grandes competidores entre sí, tanto por las características exclusivas que cada una posee, como por su popularidad.

Les propongo que toda esa energía la dediquen a hacer una fría y objetiva comparación, sin apasionamientos, de las tres bases de datos. Estableciendo diferentes entornos y poniendo a prueba las tres bases de datos sobre dichos entornos. No para obtener un ganador absoluto (dudo que eso pueda surgir), sino para contar con una matriz actualizada de las capacidades de cada una y que esa matriz nos sirva para tomar decisiones ante cada proyecto.

Yo seguiré usando Firebird predeterminadamente (me gusta la canija), pero si llego a encontrarme con una limitante crítica que alguna de las otras dos resuelva de buena forma, no dudaré en cambiar, para ese proyecto en específico, el motor de base de datos.

Un abrazo ante la caída del Muro Street.

Al González.

[adfa76]

Hola gente hace mucho que no escribia por aca.
Si bien no soy un experto en las BD mencionadas (siendo FB la que menos he usado) las 2 cosas importantes de una BD son robustes y velocidad, ni bien la primera "buena" para cualquier motor el determinante es la segunda.
Cuando empece a usar PostgreSQL la multiplataforma es un desastre comparada con cualquiera de las otras 2, la forma de hacer que funcionara en windows era con librerias de cygwin y otros inventos que hacien que el motor pareciera Frankestein. (por suerte creo que apartir de la version 8 el setup ya hacia todo). Si bien es una BD que tiene muchas cosas interesantes la performance siempre fue el punto flaco (algunas migraciones de datos de servers me han llevado su tiempito), aunque ahora es un poco más veloz nada mejor elegido como simbolo que el elefante
Mysql, es la que más he usado (que la única restricción de usarla es proporcionar el código fuente a mi entender), siempre fue muy sencilla de instalar y muy veloz (sobre todo con las tablas MyISAM, con InnoDB ya cambia un poco). Nada mejor elegido como simbolo que un Delphin. Una pena lo que esta haciendo Oracle ... pero en fin, creo que ya nos lo veiamos venir.
FB lo poco que la he usado me ha resultado bastante grato, si bien los triggers para los automerados es un trabajito más tampoco es para tanto. El que sea tan rápida y facil de usar como MySQL es una gran ventaja.
Creo que cada base tiene cosas muy interesantes para algunos menesteres pero las 3 son muy buenas bases.
Le tengo mucha fe a FB que creo que siempre lo que le falto fue prensa.

Ahora bien:
mightydragonlor (http://www.clubdelphi.com/foros/member.php?u=16415) tiene toda la , una BD NUNCA debe estar expuesta a Internet, la mayoria de los motores de BD expuestos a Internet han sido hackeados (incluido Oracle).

Saludos

[RONPABLO]

.. muy veloz (sobre todo con las tablas MyISAM, con InnoDB ya cambia un poco).
Saludos

Cuando probé MySQL lo hice sin entender muy bien porque habian tantas arquitecturas, así me fui por MyISAM, me pareció muy rápida y me fue grato, pero yo quería usar integridad referencial y estar listo para cuando salieran los procedimientos almacenados entonces cambie a InnoDB (que en ese momento entendí que debía cambiarme a esta arquitectura para tener estas caracteristicas, no recuerdo bien porque, fácilmente me falto investigar más), en fin cuando hice el cambio ahí se puede decir que tuve una experiencia nueva y poco grata, la velocidad disminuyó notablemente. Al poco tiempo empece a ver muy buenos comentarios de fb en este foro, lo estudie un poco y nuevamente a los pocos meses cambie de motor (nuevamente, antes había pasado de Paradox a MySQL) y fue algo muy bueno sentir nuevamente velocidad.