Arregla un esquema de base de datos caótico de una app generada por IA, paso a paso

Cómo luce un esquema desordenado en apps generadas por IA

Un esquema desordenado normalmente no parece estar mal al principio. La app funciona, las páginas cargan y los datos aparecen. El problema surge cuando intentas cambiar algo y te das cuenta de que no sabes qué tabla es la fuente de la verdad.

Los prototipos generados por IA suelen crear tablas deprisa: una por cada pantalla, función o prompt. Los nombres derivan con el tiempo (User, Users, user_profiles). Los formatos de ID varían (entero aquí, UUID allá). Las relaciones se insinúan en el código en vez de aplicarse en la base de datos.

Señales comunes de que tu esquema ya te está costando:

• Tablas duplicadas que almacenan lo mismo con columnas ligeramente distintas
• Identificadores confusos (múltiples campos id, o claves foráneas guardadas como texto plano)
• Nombres inconsistentes (createdAt vs created_at, status vs state)
• Columnas que mezclan responsabilidades (nombre, email y JSON crudo apretados juntos)
• "Relaciones suaves" (order.userId existe, pero nada garantiza que coincida con un usuario real)

Lo que falla raramente es "la base de datos" aisladamente. Son las funcionalidades ligadas a ella: sesiones de login que dejan de coincidir con usuarios, registros de pago que ya no se unen correctamente, informes que cuentan doble y pantallas de administración que dependen de un nombre de columna antiguo.

Un pequeño ejemplo: un prototipo puede tener tanto customers como users, y las órdenes a veces apuntan a customers.id y otras a users.email. Limpiar esto es posible, pero la triage consiste en reducir el riesgo primero: mapea lo que existe, confirma qué lee y escribe la app, y luego mejora la estructura en pasos pequeños.

Prepara redes de seguridad antes de cambiar nada

Antes de tocar migraciones, establece guardarraíles para que un paso en falso no se convierta en una caída. Muchas apps generadas por IA funcionan "lo justo" porque los datos son inconsistentes, no porque el esquema sea sólido. Tu trabajo es hacerlo más seguro sin romper lo que la gente ya usa.

Empieza con una copia de seguridad completa y luego demuestra que puedes restablecerla. No des nada por sentado. Restaura en una base de datos separada y ejecuta la app contra ella. Si no puedes restaurar, no tienes red de seguridad.

A continuación, crea una copia de staging que coincida con producción tanto como sea posible. Usa el mismo esquema, un snapshot reciente de datos y la misma versión de la app. Staging es donde pruebas migraciones, verificas pantallas clave y observas el rendimiento de consultas antes de tocar usuarios reales.

Escribe los pocos flujos de la app que deben seguir funcionando durante los refactors. Mantenlo corto y específico. Por ejemplo: "sign up -> verify email -> create project", "checkout -> payment success -> receipt", "el panel de admin carga en menos de 3 segundos".

Por último, decide un plan de rollback para cada cambio. Si una migración falla a mitad, necesitas saber si vas a avanzar (terminar la corrección) o retroceder (restaurar y revertir el código). Una lista de verificación simple ayuda:

• Copia de seguridad creada, restauración probada y marca temporal registrada
• Copia de staging actualizada y app conectada a ella
• 5–10 flujos críticos documentados y responsables asignados
• La migración es reversible (o existe un plan claro para terminarla)
• Notas de monitorización: qué métricas o logs confirmarán el éxito

Paso 1: Mapea entidades y relaciones

Antes de cambiar cualquier tabla, obtén un mapa claro de lo que la app cree que significan los datos. Las apps generadas por IA a menudo crean tablas extra que suenan similar pero representan lo mismo, o mezclan varios conceptos en una tabla. Un mapa simple te ayuda a evitar "arreglar" la parte equivocada.

Comienza listando las entidades centrales en lenguaje llano. Piensa en usuarios, cuentas, equipos, órdenes, pagos, suscripciones, facturas, mensajes. Si no puedes describir una tabla en una frase, normalmente está haciendo demasiado.

Luego, encuentra la clave primaria de cada tabla. Anota qué columna se usa como identificador verdadero (a menudo id), y señala donde falta o no es fiable. Fíjate en tablas que usan email, username o una combinación de campos como identificador. Esos tienden a generar duplicados más adelante.

Esboza las relaciones

Dibuja cómo se conectan las cosas:

• Uno-a-muchos: un usuario tiene muchas órdenes
• Muchos-a-muchos: los usuarios pueden pertenecer a muchos equipos (normalmente necesita una tabla de unión)
• Enlaces opcionales: una orden puede tener un cupón, pero no siempre

Si ves muchos-a-muchos guardados como IDs separados por comas o arrays JSON, márcalo como problema desde el principio. Afecta todos los pasos posteriores.

Traza lecturas y escrituras

Anota dónde la app lee y escribe cada tabla: qué pantallas, qué endpoints de API y qué jobs en background o tareas programadas. Una forma rápida es buscar en el código los nombres de tablas y las columnas clave.

Ejemplo: si la pantalla de checkout escribe tanto en orders como en user_orders, probablemente hayas encontrado fuentes de verdad en competencia. No fusiones nada todavía. Captúralo en el mapa.

Paso 2: Identifica duplicados y fuentes de verdad en conflicto

Las apps generadas por IA suelen crear el mismo concepto dos veces. Puedes ver customer y user, o team y org, cada una con su propia tabla y campos ligeramente distintos. Todo parece bien hasta que intentas reportar, aplicar permisos o arreglar un bug y no existe una sola verdad.

Escanea tu mapa de esquema del Paso 1 y agrupa tablas por significado, no por nombre. Extrae unas cuantas filas de cada tabla candidata. Buscas lugares donde dos tablas almacenan la misma entidad del mundo real.

Patrones comunes de duplicado incluyen tablas de identidad (customer vs user, profile vs user_details), tablas de organización (team vs org vs workspace), tablas de facturación (invoice vs bill vs payment_request) y datos de dirección repetidos en varios sitios.

Luego busca múltiples identificadores que refieran a la misma entidad. Las herramientas de IA a menudo añaden nuevos IDs a mitad del desarrollo, así que terminas con id, user_id, uid y external_id por ahí flotando. Los bugs aparecen cuando una parte de la app hace joins con uid y otra con id, y los datos se dividen silenciosamente.

También vigila el mismo campo almacenado con nombres y formatos distintos (createdAt vs created_at, teléfono guardado como texto y como número). Aunque los valores coincidan hoy, acabarán desviándose.

Elige una fuente de verdad por entidad y escríbelo. Por ejemplo: "users.id es la única clave interna de usuario; external_id es opcional y única; la tabla customers se fusionará en users." No cambies nada aún. Estás decidiendo qué gana cuando las tablas discrepan.

Paso 3: Normaliza tablas gradualmente

Normalizar solo significa hacer que cada tabla represente una cosa. En apps generadas por IA, la victoria más rápida es eliminar las partes que crean datos en conflicto mientras mantienes la app en funcionamiento.

Comienza buscando columnas que mezclan varias ideas. Ejemplos comunes son un campo address con calle, ciudad y código postal en una sola cadena, o un campo status que oculta significados extra como "paid+shipped+refunded". Estos campos son difíciles de validar y dolorosos para reportes.

A continuación, busca datos repetidos empacados en el lugar equivocado. Un olor clásico es una tabla orders con item1_name, item1_qty, item2_name, o un blob JSON de items. Funciona para una demo y colapsa cuando necesitas devoluciones, envíos parciales o totales precisos.

Prioriza la normalización donde duele:

• Inconsistencia de datos (mismo nombre de usuario guardado en tres sitios, totales que no coinciden)
• Necesidades de reporting (consultas de finanzas y ops lentas o incorrectas)
• Autenticación y permisos (roles copiados entre tablas)
• Cualquier cosa que impida añadir constraints (no puedes añadir claves foráneas aún)
• Tablas que crecen rápido (logs, eventos, órdenes)

Ve gradual para evitar romper funciones. Crea tablas nuevas junto a las antiguas, rellena datos y luego cambia las lecturas en pequeños pasos. Por ejemplo, añade order_items manteniendo los campos de items en la tabla antigua. Escribe nuevos items en ambos lugares brevemente, verifica que los totales coinciden y luego cambia la app para leer solo desde order_items.

Paso 4: Añade constraints en un orden seguro

Las constraints son donde la limpieza deja de ser "ordenar" y empieza a ser seguridad. Convierte suposiciones en reglas que la base de datos puede aplicar. La clave es añadirlas en un orden que refleje la realidad actual, no el modelo perfecto que quieres mañana.

Empieza con reglas de bajo riesgo que ya sean verdad para la mayoría de filas. Si una columna casi siempre está llena, poner NOT NULL a menudo detecta bugs reales sin sorprender a la app. Checks pequeños también son útiles siempre que reflejen cómo se comporta la app hoy (por ejemplo, "status debe ser uno de estos valores").

Antes de añadir foreign keys, limpia las filas malas existentes. Las foreign keys fallan si hay registros huérfanos, como orders.user_id apuntando a un usuario inexistente. Cuenta cuántas filas fallarían, arregla esas primero y luego aplica la relación.

Las constraints únicas van después. Evitan duplicados futuros en la fuente, pero pueden romper flujos de registro o importaciones si tus datos aún contienen duplicados. Deduplícalo primero (Paso 2) y añade unicidad solo donde refleje una regla de negocio real (por ejemplo, un email por usuario).

Si necesitas una columna nueva requerida, despliega en fases:

• Añade la columna como nullable con un valor por defecto para nuevas filas
• Rellena las filas existentes de forma controlada
• Actualiza la app para escribir la nueva columna
• Solo entonces cambia a NOT NULL

Ejemplo: una app generada por IA puede tener users.email a veces en blanco, pero la UI lo trata como obligatorio. Rellena o corrige los blancos, luego añade NOT NULL y solo después añade una restricción única en email.

Paso 5: Actualiza consultas de la app sin romper funciones

La mayoría de caídas ocurren aquí, no en la migración misma. La app sigue pidiendo columnas antiguas o escribe datos en el lugar equivocado.

Empieza por lecturas. Actualiza SELECTs y respuestas de API para que puedan manejar tanto la estructura vieja como la nueva por un corto periodo. Eso puede ser tan simple como leer primero desde las tablas nuevas y, si falta dato, recurrir a las columnas antiguas.

Un orden seguro:

• Añade consultas nuevas para el nuevo esquema, pero mantiene las antiguas funcionando
• Cambia rutas de lectura primero (idealmente detrás de una feature flag pequeña)
• Migra escrituras después para que los registros nuevos caigan en las tablas nuevas
• Mantén compatibilidad brevemente (una view, una columna de compatibilidad o dual-write temporal)
• Elimina las consultas viejas solo después de monitorizar tráfico real y corregir casos límite

Para escrituras, sé estricto con la validación. Si tu nuevo esquema divide una columna en dos tablas, asegúrate de que cada create y update rellene ambos lugares correctamente. Si haces dual-write, mantenlo corto y registra cada desajuste para poder corregirlo.

Ejemplo: un prototipo guarda el estado del pedido en orders.status y payments.status. Actualiza las lecturas para preferir la nueva fuente de verdad, luego actualiza el código de escritura para que el checkout actualice solo el nuevo campo, mientras un trigger temporal mantiene la columna antigua en sincronía.

Un flujo práctico de migración que puedes repetir

El enfoque más seguro son movimientos pequeños que puedas deshacer. Piensa en ciclos de “un cambio, una prueba”, no en reescrituras de fin de semana.

El bucle repetible

Comienza con una migración mínima que añada algo nuevo sin eliminar nada viejo. Prueba que la app sigue funcionando y avanza.

1. Añade la tabla/columna/índice nuevo que quieres (deja la estructura antigua intacta).
2. Rellena datos de forma controlada (en lotes si la tabla es grande).
3. Verifica recuentos y relaciones (filas copiadas, claves foráneas coinciden, sin NULLs inesperados).
4. Cambia lecturas primero (actualiza la app para leer de la estructura nueva) y luego monitoriza.
5. Cambia escrituras (dual-write brevemente si es necesario) y luego elimina la ruta antigua.

Después de cada ciclo, ejecuta las acciones principales del usuario de extremo a extremo en staging: registro/inicio, crear el objeto central (orden/proyecto/post) y cualquier paso de pago o correo. Estos flujos detectan los problemas de “migró bien pero la app se rompió”.

No olvides el rendimiento

La limpieza puede ralentizar cosas silenciosamente. Tras cada cambio, revisa consultas nuevas lentas, índices faltantes y consultas que dejaron de usar índices porque cambió el tipo de columna.

Mantén una nota corta para cada migración con (a) cómo revertirla y (b) qué mediste para confirmar que es correcta. Los equipos se atascan cuando cambian demasiado a la vez y no pueden decir qué paso provocó la rotura.

Errores comunes que provocan caídas durante la limpieza de esquema

Las caídas suelen producirse cuando la base de datos se vuelve más estricta antes de que los datos estén listos. Si añades foreign keys, reglas NOT NULL o índices únicos demasiado pronto, la migración puede fallar por filas existentes o la app puede empezar a lanzar errores tras el deploy.

Otra trampa es cambiar el significado de un ID. Los prototipos creados por IA a menudo mezclan IDs como strings, enteros y a veces emails como identificadores. Cambiar user_id de string a entero (o cambiar el formato de un UUID) rompe joins, payloads de API, caches y cualquier código que trate el ID como string. Si debes hacerlo, planifica una transición con backfills cuidadosos y un periodo de compatibilidad temporal.

Borrar tablas “viejas” demasiado pronto también es arriesgado. Incluso si la UI principal está migrada, algo suele estar leyendo la tabla antigua: una página de admin, un handler de webhook o un job nocturno.

Zonas de impacto fáciles de pasar por alto incluyen jobs en background, herramientas de admin, pipelines analíticos, importaciones/exportaciones y apps móviles o clientes antiguos que siguen llamando endpoints viejos.

Errores de seguridad pueden causar también caídas. Los prototipos a veces guardan tokens de auth, API keys o links de restablecimiento en texto plano. Después, alguien añade cifrado o reglas de expiración y los inicios de sesión fallan. Trata los secretos como material peligroso: rota, expira y migra con un corte claro.

Ejemplo: añades una constraint única en users.email, pero la tabla tiene [email protected] y [email protected]. Los inicios de sesión en producción fallan porque se saltó el paso de normalizar y deduplicar.

Lista rápida antes y después de cada cambio

El mayor riesgo no es el SQL. Es cambiar reglas de datos mientras la app sigue en producción ejecutando flujos reales. Usa esta lista cada vez que edites el esquema, aunque parezca pequeño.

Antes de cambiar nada

• Backup confirmado y prueba de restauración exitosa (aunque sea en una copia local).
• Tu mapa de entidades actualizado (tablas, campos clave y cómo se relacionan) y revisado por otra persona.
• Duplicados y fuentes de verdad en conflicto eliminados o claramente desaprobados (sin nuevas escrituras).
• Has comprobado la limpieza de datos para la próxima constraint (nulls, filas huérfanas, valores inválidos).
• Un plan de rollback escrito para este cambio exacto (qué desharás primero y cómo verificarás que es seguro).

Pausa un minuto y escribe el radio de impacto: qué pantallas o endpoints rompen si esta migración falla.

Después del cambio

• Ejecuta los flujos clave de usuario de extremo a extremo: registro, inicio de sesión y la transacción principal por la que existe la app.
• Confirma que la app lee desde la nueva fuente de verdad (y no recurre silenciosamente a columnas antiguas).
• Verifica que las constraints se aplican realmente (intenta insertar una fila mala en un entorno de prueba).
• Revisa logs por errores de consulta nuevos y consultas lentas.
• Actualiza nuevamente el mapa de entidades para que el siguiente cambio parte de la realidad.

Escenario de ejemplo: limpiar users y orders en un prototipo

Un problema común de prototipo: abres la base de datos y encuentras users, customers y accounts que almacenan email, nombre y campos tipo contraseña. Las órdenes pueden apuntar a customers.id en un sitio, a users.id en otro y a veces solo guardan una cadena con un email.

Empieza eligiendo una fuente de verdad para identidad. Si la app tiene login, users suele ser el ancla mejor. Mantén las demás tablas por ahora, pero trátalas como perfiles que se fusionarán.

Para mapear IDs de forma segura, añade una columna temporal como customers.user_id y rellénala emparejando por un valor estable (a menudo email normalizado). Para registros que no emparejen con claridad, crea una lista de revisión pequeña y corrígelos manualmente antes de añadir constraints.

Después, mira las órdenes. Los prototipos suelen repetir campos de items en la tabla orders (como item_1_name, item_2_price) o almacenar un blob JSON que cambia de forma. Crea una tabla order_items con order_id, product_name, unit_price, quantity y rellénala desde los datos existentes. Mantén columnas antiguas temporalmente para que la app siga funcionando mientras actualizas consultas.

Tras limpiar y mapear datos, añade constraints con calma:

• Añade NOT NULL solo en campos que hayas rellenado completamente
• Añade constraints únicas (como users.email) después de eliminar duplicados
• Añade foreign keys (orders.user_id -> users.id, order_items.order_id -> orders.id)

Finalmente, prueba lo que los usuarios notarán de inmediato: inicio de sesión y restablecimiento de contraseña, registro (incluido el caso “email ya usado”), creación de órdenes y items, totales de checkout y la página de historial de pedidos.

Próximos pasos: cuándo traer ayuda experta

Si la limpieza sigue en sandbox, normalmente puedes avanzar con cuidado y aprender en el camino. Una vez que hay usuarios reales y datos reales, el riesgo cambia rápido. Una migración aparentemente inofensiva puede romper el inicio de sesión, corromper órdenes o exponer datos privados.

Considera traer ayuda experta si hay autenticación o permisos implicados, si manejas pagos o facturas, si almacenas datos sensibles, la app está en producción y el downtime no es opción, o la lógica de la base de datos y la app están enmarañadas.

Si lo delegas, obtendrás resultados más rápidos si puedes compartir un volcado de esquema y un backup reciente, una lista corta de flujos críticos (registro, checkout, reembolsos, acciones admin), los errores más grandes que ves (consultas lentas, migraciones rotas, totales inconsistentes) y cualquier incidente conocido (duplicados, registros faltantes, preocupaciones de seguridad).

Si estás lidiando con un prototipo generado por IA y necesitas una revisión end-to-end (esquema, lógica y seguridad juntos), FixMyMess en fixmymess.ai se centra en la remediación de apps creadas por IA y puede comenzar con una auditoría de código gratuita para identificar los problemas de mayor riesgo antes de ejecutar migraciones.