MySQL Vs Firebird

[subzero]

Excelente... ya que estamos en este tema algo que aun no me queda claro es cuántas BD simultaneas pueden ser ejecutadas en Firebird? (mi tercera pregunta)

[Casimiro Notevi]

¿Qué quieres decir exactamente con simultáneas? ¿Poder tener conectadas varias al mismo tiempo?
Si esa es la pregunta, todas la que quieras, mientras tengas memoria, recursos, etc.

[mamcx]

Cuando tu tienes el control del stack de una aplicación, usa lo que quieras. Hay toda una amplia gama de servicios y aplicaciones que usan bases de datos mucho mas exoticas que Firebird, asi que no hay razon para no usarlo.

Mientras que se puede usar MySql de forma responsable y eligiendo bien su configuracion, MySql es el javascript/php de las bases de datos: Puedes corromper la información si la miras mal y no te sabes los multiples casos y sub-casos especiales de como no o si debes hacer las cosas:

http://blog.ionelmc.ro/2014/12/28/te...choices-mysql/

Mejor dicho: Si quieres una base de datos *confiable*? MySql es la *ultima* opcion en el mundo relacional.

[subzero]

Bueno, quiero agradecer a todos por sus respuestas, continuaré con Firebird y espero poder comentarles como va mi nuevo proyecto.


Saludos!

[roman]

Empezado por subzero

Bueno, quiero agradecer a todos por sus respuestas, continuaré con Firebird y espero poder comentarles como va mi nuevo proyecto.

Es bueno que hayas elegido Firebird si es lo que te acomoda y sobre todo que ya lo conoces. Sin embargo me gustaría puntualizar que información como la del enlace de mamcx es prejuiciada de nacimiento. Jamás he escuchado de un sitio web cuyos datos se hayan corrompido por el uso de mysql y, desde luego, jamás me ha sucedido a mi. El hecho de que algo sea popular no necesariamente lo invalida y hay muchos, muchos sitios y plataformas web montadas sobre mysql (y para la bilis de mamcx , sobre php) que tienen éxito y ninguna se queja de datos corruptos. Simplemente que cuando tomas una herramienta con el dictamen previamente establecido, seguramente hallarás que no te gusta

// Saludos

[mamcx]

Acoto lo que mencione de mysql:

What the defaults allow:

- Storing invalid dates like '0000-00-00' or '2010-01-00' [1].
- Silently treating errors like:
-- Specifying an unavailable storage engine. It will use the default engine, silently [2].
-- Inserting invalid data. Larger strings get truncated to the maximum length. Larger integers get truncated to the maximum. Other things get converted to NULL if the column allows that. All silently [3].

....
Yes, the index on utf8 columns is limited to 255 characters [4]. If you need to store emoticons like an angry face �� - and most probably you'd want to, given the predicament - then you're out of luck, you need a different charset, utf8mb4 [5]. But that means smaller index, only 191 characters [11].
....

Noten que todo tiene enlaces a los docs. MySql permite perdida de datos, incluyendo casos en donde el *tipo* de datos se supone que no lo permite. Crear fechas que no son fechas? Guardar utf-8 pero no en el rango de utf-8? Truncar strings cuando no es el caso?

Y TODO SILENCIOSAMENTE!

Yep. Mysql, php, javascript... comparten esas idiosincracias

Asi que:

Pueden estar seguros que los datos que tienen *realmente* son validos?

---

P.D: Recuerdo hace años que manejabamos Fox/dbase que exhibia algunos problemas parecidos. Nos dimos cuenta de datos corruptos en una instancia luego de que el cliente llevara varios meses operando, y solo porque alguien le dio preguntar porque cierto registro no salia (se pueden imaginar lo poco usual de darse cuenta en una tabla de cientos/miles/millones que *cierto registro* no cuadra.

Asi que "datos corruptos" no era un apunto a "daño en las estructuras fisicas" que es grave, pero visible; mas bien a "datos dentro de la tabla" que es invisible.

P.D 2:

Comparen, de la misma pagina y autores:

http://sql-info.de/mysql/gotchas.html

http://sql-info.de/postgresql/postgres-gotchas.html

[roman]

Es que, lo que no cabe no cabe. Para mi es así de sencillo. No veo ningún problema en que el motor trunque un dato demasiado grande. Es responsabilidad del programador. Simplemente son particularidades de cada gestor/lenguaje.

Como dije antes, y lo reitero, jamás he escuchado de un sistema que tenga problemas por una corrupción de datos. ¿Que MySQL tiene sus bemoles? Claro que sí, y, ciertamente, no será apto para todo tipo de sistemas. De ahí a invalidarlo contra toda evidencia práctica, pues bueno, es mucho rizar el rizo.

// Saludos