http://db-engines.co...ySQL;PostgreSQL

Firebird Vs Mysql Vs Postgresql - Comparativa en Db-Engines
Comenzado por
poliburro
, ene 29 2015 10:06
2 respuestas en este tema
#1
Escrito 29 enero 2015 - 10:06
Pues me he econtrado con una herramienta en DbEngines que permite hacer comparativas entre múltiples bases de datos. Me ha parecido tan interesante que copio aquí el resultado:
http://db-engines.co...ySQL;PostgreSQL
http://db-engines.co...ySQL;PostgreSQL
#2
Escrito 29 enero 2015 - 12:07
muy parecidos los resultados, lo unico encontra que veo de firebird es no tener metodos de replicacion internos, aunque bien se pueden utilizar herramientas de terceros.
Supongo que a la hora de elegir una bdd nos debemos orientar desde el lenguaje de programacion que se utilizará.
Supongo que a la hora de elegir una bdd nos debemos orientar desde el lenguaje de programacion que se utilizará.

#3
Escrito 29 enero 2015 - 02:37
FireBird cojea de tres patas, pero es mi preferido por el volumen de datos que necesitan mis apps (no uso replicacion ni balanceo de carga).
1) Multiprocesador. Solo usa uno y medio! La V3.0 (ahora en beta) ya utiliza todos los procesadores, or fin, eso permite servir a muchos mas clientes sin que una sql de uno bloquee a los demás. Yo ya he adaptado mis programas a V3.0, solo necesite modificar los procedures para que los select campo into :var no llevasen ya esos : del :var, que ya no se acepan. Por lo demas, perfecto, aunque la instalacion ya no pone el user y pass por defecto por temas de seguridad, un incordio para mi.
2) Replicacion. Hay herramientas de terceros que usan los triggers after insert or update de cada tabla para replicar el dato en la copia. El problema es que cada vez que cambias la estreuctura has de volver a pasar la herramienta para que actualice los triggers, y eso hace inviable su uso desatendido.
3) Balanceo de carga. Sin replicacion no hay balanceo posible, pero si hay herramientas que lo hacen de terceros, asi que mezclando ambas si que se puede, pero es complejo, solo vale para estructuras que no cambian nunca casi.
Por lo demas, y dado que MySql no es realmente open pues el driver de base de datos "buena" con consistencia es closed, pero bueno, quien se lee el codigo?
1) Multiprocesador. Solo usa uno y medio! La V3.0 (ahora en beta) ya utiliza todos los procesadores, or fin, eso permite servir a muchos mas clientes sin que una sql de uno bloquee a los demás. Yo ya he adaptado mis programas a V3.0, solo necesite modificar los procedures para que los select campo into :var no llevasen ya esos : del :var, que ya no se acepan. Por lo demas, perfecto, aunque la instalacion ya no pone el user y pass por defecto por temas de seguridad, un incordio para mi.
2) Replicacion. Hay herramientas de terceros que usan los triggers after insert or update de cada tabla para replicar el dato en la copia. El problema es que cada vez que cambias la estreuctura has de volver a pasar la herramienta para que actualice los triggers, y eso hace inviable su uso desatendido.
3) Balanceo de carga. Sin replicacion no hay balanceo posible, pero si hay herramientas que lo hacen de terceros, asi que mezclando ambas si que se puede, pero es complejo, solo vale para estructuras que no cambian nunca casi.
Por lo demas, y dado que MySql no es realmente open pues el driver de base de datos "buena" con consistencia es closed, pero bueno, quien se lee el codigo?