empresas que usan firebird

[[Delphius]]

Yo mucho no puedo aportar... Casi se mandó un buen discurso proveniente de sus años de experiencia y eso vale.
Si algunos informes son mas lentos, quizá sea como te han dicho disponer de un servidor con una DB a modo de sólo lectura con los últimos backups para consultar en vez de que sea sobre la DB operativa. Esto podría alijerar la carga, aunque tiene la contra el factor económico y que se deberá llevar a cabo un mejor control de los backups.

Otra de las posibilidades, que podrían ayudar a mejorar el rendimiento sobre las consultas para generar informes es aplicar un poco de desnormalización. Es decir, romper un poco las reglas normales y disponer de datos ya preprocesados, calculados, o estimados. Quizá se consiga un aumento del tamaño de la base de datos, pero al menos con estas tablas desnormalizadas, bien pensadas y estudiadas, con sus respectivos índices, etc. Generar un informe que requiera de por dar un ejemplo extremo, 10 joins, 5 group by, 7 order by, 20 coalesce, y 10 Max()s quizá pueda reducirse, siendo optimistas a la mitad.

Una solución mágica seguro no hay. Tirar de un lado, invetibalemente tendrá alguna desventaja y repercusión en otro punto. Es el Yin-Yang... ni lo uno, ni lo otro, ni mutuamente excluyentes, ni mutuamente dependientes... es esa sensación rara de que al final damos vueltas en círculos

¿Quieres tirar por el lado de mejorar la base de datos? Te rompe los esquemas y a adaptar de nuevo el sistema para absorver los cambios.

¿Quieres adquirir más poder? Tienes que sacar la billetera...

Me hiciste acordar ahora de otra frase: Rapido, Bueno, Barato. Elija 2 cualquiera.

Saludos,

[[Chris]]

Daré por sentado que cuando te refieres a informe, te refieres a una CONSULTA SQL con sus JOIN'S y GROUP BY's, ORDER BY's, etc. a como ha dicho Delphi.

Desde mi punto de vista recomendaría:
Lo primero, tomando lo dicho por casimiro, es "debuguear" las consultas y ver en que partes puedes optimizarlas.
Segundo: Tomando la consideración de Delphius, puedes reducir el uso de JOIN's o GROUP BY's desnormalizando los datos. Por ejemplo, si unes dos tablas para solamente obtener el nombre completo del cliente, puedes evitarte hacer la unión simplemente guardando el nombre del cliente en la tabla de Ventas, por poner un ejemplo.
Tercero: Anteriormente dicho por Casi, instala Linux.
Cuarto: Aumenta la RAM a la mayor cantidad que puedas y utiliza un disco interno dedicado con la interfaz de conexión más rápida disponible. (Este es el más fácil de los cuatro pero no es una solución a largo plazo).

Ahora, no sé si no he entendido el punto o qué, pero veo con recelo eso de partir la DB. No entiendo que rendimiento puedas obtener si partes la DB para luego consultar las distintas partes. Sino me equivoco, desde la versión 2.5 de Firebird puedes hacer conexiones a otras base de datos desde los procedimientos almacenados. Nunca he probado esta funcionalidad, pero estoy casi seguro que tiene su penalidad en el tiempo que se tarta en hacer la conexión. Sin embargo, el tiempo que se tarda en hacer la conexión puede ser relativamente muy enferior al tiempo de espera para generar un informe con todos los datos almacenados en una misma DB. En este caso puedes tomar provecho de esta funcionalidad. Pero esto sería algo que tienes que hacer con mucho cuidado para obtener el máximo rendimiento posible. Desde mi punto de vista primero probaría las cuatro recomendaciones anteriores.

Cambiar el motor de base de datos es trabajo. Tienes que estar muy justificado del por qué hacer el cambio. A cómo te han dicho, Oracle no sería recomendable. Mejor utiliza PostgreSQL que trae replicación nativa. Ya Casimiro te explicó el por qué.

Por último, estoy seguro que no manejas el nivel de transacciones que tiene Amazon o Youtube. Pero ya que preguntas, tengo entendido que estas empresas utilizan una arquitectura de base de datos llamada "NOSQL". Son motores que están optimizados para escribir y leer rápido. Exceptuando lo básico, en ellos no existe el lenguaje SQL. No es la gran cosa. Simplemente se reducen a obligarte a hacer desnormalización de datos a cómo te ha dicho Delphius y yo lo recojo en el segundo punto. Si quieres la mayor potencia, tienes que dar a cambio el lenguaje SQL.

Por último, quiero cerrar diciéndote que Firebird es uno de los motores SQL más rápidos que puedes encontrar. Muy superior a PostgreSQL y Oracle. Su diseño sencillo lo hace uno de los motores más ágiles. Debes de dejar la idea que otro motor te brindará mejor rendimiento, porque créelo, será casi imposible.

Saludos.