Acoto lo que mencione de mysql:
Cita:
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