MySQL Vs Firebird

[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

[roman]

Por otra parte, como en el caso de las fechas y otras cosas que mencionan en el "artículo", muchas se controlan configurando el gestor. Pero como los autores consideran que ciertas opciones deben estar por defecto, para ellos es suficiente para invalidar la herramienta, cuando es una percepción personal. Si no les gusta leer la documentación previamente y las cosas no son acorde a lo que esperaban, sinceramente ya es bronca de ellos

// Saludos

[mamcx]

Empezado por roman

Como dije antes, y lo reitero, jamás he escuchado de un sistema que tenga problemas por una corrupción de datos.

Obvio que no, no ves que MySql silencia la perdida de datos? Y como que no has oido? Te lo estoy mostrando, con fuentes! Directas de la *documentación* de mysql donde dice que PERDERAS datos!

El problema no es que no quepa. Es que la perdida de datos es *silenciosa*. MySql responde "todo ok!" cuando cualquier otro motor decente te retorna "No, no me cabe esos datos!".

Nota por ejemplo:

https://mzsanford.wordpress.com/2010...l-and-unicode/

P.D: Mientras que el problema del UTF se "arregla" cambiando de encoding, el caso que quiero que vean es que ademas hay que tener cuidado con los acentos.

Empezado por roman

muchas se controlan configurando el gestor

Si delphi fuera igual, si tienes una variable tipo Date y le podes poner un dato invalido, diras que es un problema TUYO o de la HERRAMIENTA?

MySql tiene problemas fundamentales, que como muchas otras cosas los usuarios deben aprender a evadir o hacer workaround (y cuanto apuesto que muchos ni se imaginan nada de esto) es otra cosa. Pero dado el caso: Es MySql recomendable como base de datos, teniendo opciones como Postgres, firebird, oracle, etc? Pues no como real primera opcion, si nos atenemos a ser profesionales e ingenieros, en vez de mirar que es mas facil o popular.

[roman]

Precisamente. Tú lo has dicho: DOCUMENTACIÓN. Esta documentado, ¡qué barbaridad! Y no. No responde a todo que ok. Genera una advertencia o un error según tu configuración. Ya si el programador decide ignorar la advertencia pues es cosa suya.

// Saludos

[mamcx]

Ok Roman, y si la entrada de datos se hace desde un GUI/Pagina Web o similar, no por medio de un programador... que pasa?