Estoy migrando una aplicación interna de MySQL a PostgreSQL y me encontré con algo que no esperaba: el manejo de las fechas parece ser más estricto en Postgres. En MySQL tenía algunos campos con valores como '0000-00-00' para indicar una fecha no establecida, y ahora la importación falla. Me pregunto cómo manejan ustedes estos casos de datos faltantes o inválidos en sus proyectos, sin romper la integridad referencial que precisamente buscaba al cambiar de motor.
|
Qué hacer con fechas inválidas al migrar MySQL a PostgreSQL?
|
|
En PostgreSQL las fechas no pueden ser 0000 00 00 ese valor no es válido para tipo date. Una ruta habitual es normalizar durante la importación convertir esos registros a NULL y si es relevante añadir un indicador date_known para conservar el significado de que la fecha no estaba establecida. Después usar NULL en claves foráneas y manejarlo en la capa de aplicación o con una vista que traduzca NULL a un estado conocido.
Me desagrada ese truco de MySQL cuando se usa 0000 00 00 para evitar validar. Si ya migras lo justo es abandonar esa practica y modelar lo faltante con NULL y un flag. Postgres es estricto para evitar datos dañinos.
Uf la migración duele cuando la gente usa fechas que no son fechas y el motor se queja. Las fechas siguen siendo una parte sensible del modelo.
¿Y si miramos la pregunta desde otra perspectiva que busque la verdad de la integridad? a veces conviene separar la idea de fecha conocida de la fecha en si usando un booleano y dejar la columna date para valores reales.
En un proyecto hicimos una migración con una etapa de staging y normalizamos fechas antes de pasar a producción. Convertimos valores sin fecha a NULL y añadimos un indicador date_known para saber si la fecha fue establecida. También definimos restricciones y vistas para que las consultas antiguas sigan funcionando.
Una forma practica es usar dominios de fecha que acepten NULL y un estado para la fecha y crear índices parciales para mantener el rendimiento.
|
|
« Tema anterior | Tema siguiente »
|

