Oracle empieza a cerrar MYSQL

[[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 Noteví]

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í está el enlace.

[roman]

Empezado por Chris

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?

Empezado por 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 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]]

Empezado por roman

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]

Empezado por Chris

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? Sólo 8 carácteres?? No hay ninguna forma de poner contraseñas más largas?

[Casimiro Noteví]

Empezado por casimiro

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:

Empezado por casimiro

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.

Empezado por roman

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

Cierto

[Casimiro Noteví]

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, where user names and passwords are stored, is now called RDB$USERS. There is no longer a table named "users" but a new 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 in the section about authentication later in this chapter.
For instructions on updating previous security databases, refer to the section Dealing with the new security database at the end of this chapter.
Better password encryption

A. Peshkov
Password encryption/decryption now uses a more secure password hash 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 now uses the Services 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.

[ASAPLTDA]

Empezado por mcs

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 Noteví]

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

[[RONPABLO]]

Empezado por mcs

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 Noteví]

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/cat7/