Cita:
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