Desenreda relaciones enmarañadas de bases de datos con un rediseño claro

Cómo se ven las relaciones "espagueti" en la práctica

Las relaciones enmarañadas en una base de datos significan que tus tablas están atadas de formas desordenadas y sorprendentes. En lugar de pocos caminos claros (por ejemplo, users -> orders -> payments), tienes una red de enlaces cruzados donde muchas tablas apuntan a muchas otras, las reglas son inconsistentes y nadie puede explicar por qué existe una relación. El esquema funciona técnicamente, pero es difícil razonar sobre él.

Se nota en el trabajo diario. Un pequeño cambio (añadir un campo, ajustar un estado, separar una característica) se convierte en una reacción en cadena: una migración rompe un informe, una corrección para un bug provoca otro, y las consultas simples necesitan seis joins más filtros raros para evitar duplicados. La gente empieza a copiar consultas de tickets antiguos porque entenderlas desde cero lleva demasiado tiempo.

Señales tempranas (incluso si no eres experto en bases de datos)

A menudo puedes detectar el desorden sin leer cada tabla. Observa algunos patrones:

• El mismo concepto aparece en varios lugares (por ejemplo, customer_id y buyer_id, o tres columnas status diferentes).
• Las tablas tienen muchas columnas nullable que solo aplican en casos especiales (una tabla para todo).
• Ves tablas de join para cosas que no deberían ser many-to-many, o relaciones many-to-many usadas como atajo.
• Borrar un registro da miedo porque no sabes qué más romperá.
• La gente no tiene claro quién “posee” un dato, así que lo guardan donde conviene.

Un ejemplo simple: tienes users, orders, invoices, payments y tickets. En un diseño limpio, cada una tiene un rol claro. En un esquema espagueti, tickets tiene order_id, payments tiene ticket_id, users tiene last_invoice_id y invoices también apuntan a users por el “plan actual”. Ahora un bug de facturación involucra cuatro tablas y dos ideas distintas de qué significa “actual”.

El objetivo aquí es una limpieza práctica: reconocer dependencias circulares, tablas sobrecargadas y propiedad poco clara, y rediseñar hacia claridad y mantenibilidad. Sin teoría profunda ni debates de normalización. Quieres un esquema que un nuevo compañero pueda leer, consultar y cambiar sin miedo.

Haz un mapa rápido del esquema actual

Antes de rediseñar, obtén una imagen simple de lo que tienes. El objetivo no es un diagrama ER perfecto, sino un mapa compartido que ayude a tu equipo a hablar sobre las mismas tablas de la misma manera.

Comienza listando cada tabla y escribiendo una frase simple sobre lo que representa. Si no puedes describir una tabla sin usar el nombre de otra tabla, trátalo como una señal de aviso.

Luego describe las relaciones en palabras cotidianas: “un usuario tiene muchos orders”, “un order tiene muchos items”, “un producto puede estar en muchos orders”. Manténlo simple. Intentas ver la intención y la forma, no cada caso borde.

Un pase de mapeo de 30 minutos que realmente ayuda

Limita el tiempo y captura solo lo necesario para tomar decisiones:

• Propósito de la tabla: una frase, más las 3 columnas principales que la hacen única
• Relaciones clave: a qué apunta (foreign keys) y qué le apunta
• Puntos críticos: tablas tocadas por muchas funciones, pantallas, jobs o servicios
• Escritura vs lectura: dónde la app inserta/actualiza frente a dónde solo selecciona
• Choques de nombres: tablas o columnas con nombres parecidos pero significados distintos

Después marca claramente tus puntos calientes. Una tabla “caliente” no es automáticamente mala, pero ahí suele empezar el espagueti: las correcciones rápidas se acumulan, aparecen columnas extra y cada nueva característica depende de ella.

También captura el flujo de datos. Muchos esquemas desordenados vienen de no saber la fuente de la verdad. Para cada tabla, anota quién la escribe (flujo de registro, panel admin, job en background, script de importación) y quién solo la lee (dashboards, reporting, búsqueda). Si una tabla se escribe desde cinco sitios, espera reglas inconsistentes y bugs sorprendentes.

Finalmente, crea un pequeño glosario. Elige las 5–10 palabras que generan discusión: “account”, “user”, “customer”, “workspace”, “org”, “member”. Escribe una frase para cada una. Por ejemplo: “Account = entidad de facturación. User = persona que inicia sesión. Customer = la compañía que paga del account.” Esto evita que los debates de rediseño se conviertan en confusión de lenguaje.

Si heredaste un prototipo generado por IA, este mapa suele ser donde primero notas duplicados como users, app_users y customers intentando significar lo mismo.

Cómo identificar dependencias circulares

Una dependencia circular ocurre cuando las tablas dependen unas de otras en un bucle. La versión más simple es A apunta a B y B apunta de vuelta a A. En apps reales suele volverse A -> B -> C -> A, y nadie puede explicar cuál es el padre.

Un ejemplo común: tienes users y teams. Un usuario pertenece a un equipo (users.team_id). Alguien añade “team owner” como foreign key hacia users (teams.owner_user_id). Ahora insertar el primer equipo y el primer owner es difícil: ¿cuál debe existir primero?

Los ciclos aparecen en varios lugares:

• Autorreferencias como categories.parent_id, especialmente cuando otras tablas también apuntan a categories y permites anidamiento profundo.
• Tablas de join que calladamente se convierten en entidades “reales” y empiezan a apuntar de vuelta a ambos lados más tablas extras (roles, permissions, invitations).
• Tablas de lookup o status compartidas que crecen hasta convertirse en un hub. Si statuses empieza a referenciar orders para el “estado actual del pedido”, has creado un bucle.

Puedes detectar ciclos de dos maneras: leyendo foreign keys y observando el comportamiento de la app.

Desde las foreign keys, dibuja una flecha por cada FK (hijo -> padre). Si puedes seguir flechas y volver al punto de inicio, tienes un ciclo.

En el comportamiento de la app, los ciclos suelen verse así:

• No puedes crear registros sin hacks (FKs nullable “solo por ahora” que nunca se corrigen).
• Borrar un registro explota en deletes bloqueados o, peor, cascadas sorpresa.
• Las actualizaciones requieren transacciones multi-paso porque cada tabla necesita a la otra para ser válida.
• Ves “filas temporales” o IDs de marcador de posición usados durante sign-up, checkout u onboarding.

Las dependencias circulares son dolorosas porque esconden la propiedad. Es difícil razonar qué debería existir primero, qué puede borrarse con seguridad y qué datos son realmente opcionales.

Cómo detectar tablas sobrecargadas

Una tabla sobrecargada intenta representar más de una cosa del mundo real. Se convierte en un cajón de sastre: se añaden campos porque “está un poco relacionado”, hasta que la tabla contiene varios significados a la vez.

Una comprobación rápida: si no puedes describir lo que representa una fila en una frase clara, la tabla probablemente está sobrecargada.

Pistas rápidas en el esquema

A menudo detectas el problema solo escaneando columnas. Las tablas sobrecargadas tienden a tener muchas columnas nullable, claros grupos de columnas no relacionadas (facturación junto a envío y soporte), y patrones repetidos como *_status, *_date, *_note que parecen flujos de trabajo separados amontonados en una fila. Otro indicio es una tabla con foreign keys hacia partes no relacionadas de la app (payments, marketing, support, inventory) desde un solo lugar.

Ninguno de estos por sí solo prueba el problema, pero cuando aparecen varios juntos es una señal fuerte.

Pistas que esconde la propia data

Los datos suelen contar la historia más claramente que el esquema.

Si consultas la tabla y ves tipos de registro mezclados, notarás valores y reglas inconsistentes. Por ejemplo, algunas filas usan status = 'paid', otras status = 'closed' y otras lo dejan en blanco porque ese estado no aplica a ese tipo de fila.

Otro olor es una tabla donde los “campos tipo” están por todas partes: record_type, source_type, owner_type, target_type. Eso suele significar que la tabla está actuando como varias tablas disfrazadas.

Las tablas sobrecargadas son fábricas de bugs porque partes distintas de la app hacen suposiciones diferentes sobre lo que es una fila. El reporting también se vuelve poco fiable: dos equipos pueden ejecutar “total de registros activos” y obtener números distintos porque cada uno filtra subconjuntos distintos de columnas.

Cómo decidir qué separar

Al rediseñar, las divisiones suelen caer en tres categorías:

• Separar por concepto cuando la tabla contiene sustantivos distintos (por ejemplo, mezclar detalles de “customer”, “vendor” y “employee”).
• Separar por ciclo de vida cuando una fila intenta cubrir etapas que deberían estar separadas (borrador vs enviado vs cumplido, cada uno con campos requeridos distintos).
• Separar por actor cuando equipos o sistemas distintos poseen partes diferentes del registro (detalles de pago propiedad de finanzas vs detalles de ticket propiedad de soporte).

Una prueba práctica: lista las 5 consultas y escrituras principales que tocan la tabla. Si naturalmente caen en grupos separados con reglas y campos requeridos distintos, has encontrado un punto de separación limpio.

Encuentra propiedad poco clara y conceptos duplicados

Mucho del dolor en la refactorización de bases de datos viene de un problema simple: nadie sabe qué tabla es la fuente de la verdad.

La propiedad significa que una tabla es el lugar donde se crea y actualiza un hecho, y todas las demás tablas la tratan como referencia de solo lectura (o una caché claramente etiquetada). Cuando la propiedad es clara, los bugs son más fáciles de arreglar porque sabes dónde debe ocurrir el cambio. Cuando no lo es, las pequeñas ediciones se convierten en sorpresas porque la misma “verdad” existe en varios lugares.

Dónde suele romperse la propiedad

La propiedad se rompe después de trabajo de prototipo rápido, especialmente cuando la gente copia patrones de otras funciones.

Busca estos patrones:

• Dos tablas que ambas parecen “el cliente” (por ejemplo, customers y client_accounts) y las dos se actualizan desde la app.
• Una tabla “profile” compartida usada por users, admins y vendors, donde rutas de código distintas sobrescriben campos de los demás.
• Estado o configuraciones almacenadas en varios sitios (una columna en users, más una fila en user_settings, más JSON en metadata).
• Una tabla que guarda hechos de negocio y campos de conveniencia UI juntos (detalles de facturación mezclados con nombre para mostrar y avatar).
• Foreign keys que apuntan en ambos sentidos porque ninguno de los lados “posee” la relación.

Detecta conceptos duplicados antes de renombrar nada

Los conceptos duplicados son engañosos porque los nombres difieren. Una forma rápida de hallarlos es listar los sustantivos clave del negocio (user, account, customer, org, order) y luego buscar en el esquema todas las tablas y columnas que los representan.

Ejemplo: tu app tiene users.email y también contacts.email, y ambas se editan durante el registro. Ahora debes decidir cuál dirige el login, las notificaciones y la facturación. Si la app puede escribir en ambas, tendrás deriva.

La solución es elegir una fuente de la verdad y hacer explícitas las responsabilidades: una tabla puede escribir el valor canónico; otras tablas pueden leerlo o cachearlo, pero las cachés deben estar claramente etiquetadas y ser fáciles de reconstruir.

Reglas de nombres simples reducen la ambigüedad rápido:

• Usa una palabra para un concepto (customer vs client: elige una).
• Pon campos canónicos en la tabla propietaria; evita duplicarlos en otros lugares.
• Nombra referencias de forma consistente (customer_id, no custId en una tabla y client_id en otra).
• Si debes cachear, dilo (customer_email_cached).

Principios de rediseño que mantienen las relaciones legibles

Si quieres desenredar relaciones espagueti, haz que lo importante sea obvio: de qué trata el sistema, quién posee qué y qué puede borrarse o cambiarse con seguridad después.

Empieza con las pocas entidades de las que depende todo

Elige el pequeño conjunto de entidades núcleo que deben existir antes de que cualquier otra cosa funcione. Suelen ser cosas como User, Account, Organization, Product, Order o Invoice.

Si tu esquema hace que una entidad núcleo dependa de registros opcionales (como logs, settings o tags), acabas con inserts frágiles y deletes confusos.

Una prueba rápida: si una tabla no puede crearse sin unir tres tablas más, probablemente no sea una entidad núcleo. Puede ser una tabla de relación o una tabla de detalles.

Mantén las relaciones explícitas y previsibles

Los esquemas buenos se sienten aburridos en el mejor sentido. Unos cuantos hábitos marcan una gran diferencia.

Separa los datos de referencia (listas pequeñas y poco cambiantes como countries, statuses, plan types) de los datos transaccionales (orders, payments, events). Las tablas de referencia deberían raramente depender de tablas transaccionales.

Usa tablas de join claras para many-to-many. Si Users pueden pertenecer a muchos Teams, prefiere una tabla UserTeam con solo las claves y un par de campos (role, created_at) en lugar de amontonar arrays o columnas duplicadas en ambos lados.

Sé consistente con claves primarias y foráneas. Elige un estilo de clave (UUID o entero) y úsalo en todas partes a menos que haya una razón fuerte para no hacerlo. Mezclar estilos complica joins y depuración.

Nombra columnas según su función. Usa team_id cuando apunta a Teams. Evita nombres genéricos como ref_id o data_id que ocultan la propiedad.

Documenta el ciclo de vida en palabras simples: qué se crea primero, qué puede crearse después y qué nunca debe borrarse mientras existan otros registros.

Aquí hay un escenario concreto: si Order necesita User, y User necesita latest_order_id para existir, tienes un bucle que provocará sign-ups rotos y escrituras parciales. La solución suele ser quitar las foreign keys tipo “latest_*” del padre y calcularlas con una consulta (o usar una tabla de resumen separada que no bloquee inserts).

Paso a paso: refactorizar sin romper la app

La forma más segura de desenredar relaciones espagueti es tratarlo como cirugía: área pequeña, plan claro y comprobaciones tras cada cambio. Elige un flujo que puedas describir en una frase, como “crear un pedido” o “invitar a un compañero”, en lugar de intentar arreglar todo el esquema de una vez.

Un patrón de migración seguro

Empieza diseñando las tablas nuevas al lado de las antiguas. Mantén las tablas actuales funcionando mientras añades otras más limpias con nombres, claves y propiedad claros. Por ejemplo, si una tabla mezcla campos de perfil, tokens de auth y estado de facturación, diseña nuevas tablas para que cada concepto tenga su casa.

Luego mueve datos y comportamiento en etapas:

• Elige un área pequeña y escribe las consultas exactas que usa hoy la funcionalidad.
• Crea las tablas nuevas junto a las viejas (no borres ni renombres aún).
• Backfill de datos de lo viejo a lo nuevo y valida conteos y reglas clave (unique keys, foreign keys, not-null) con consultas simples.

Después del backfill, migra lecturas antes que escrituras. Cambiar lecturas primero te deja ver si la app sigue mostrando los mismos resultados mientras la ruta de escritura antigua mantiene el flujo. Una aproximación simple es añadir un feature flag o toggle de configuración para activar/desactivar las lecturas nuevas durante las pruebas.

Cuando las lecturas sean estables, mueve las escrituras con cuidado:

• Cambia escrituras a las tablas nuevas y mantén un periodo corto donde también escribes en las tablas antiguas si el riesgo de rollback es alto.
• Elimina paths de código muerto y columnas antiguas solo cuando estés seguro de que nadie depende de ellas.

Fija las reglas para que se mantenga limpio

No te quedes solo en la estructura. Añade constraints que reflejen las reglas que realmente quieres (por ejemplo, “un order debe tener exactamente un customer” o “una membership debe ser única por user y workspace”).

Añade comprobaciones pequeñas también: un script en migración que compare conteos, una consulta diaria que busque filas huérfanas o una prueba básica alrededor del flujo que acabas de tocar.

Ejemplo: limpiar un esquema confuso de orders y users

Un caso común: el checkout funciona en dev, pero en producción ves errores aleatorios de “user not found”, cargos duplicados y orders con dirección equivocada. El esquema suele tener tablas familiares (users, orders, payments), pero las relaciones están tan enredadas que pequeños cambios rompen otra cosa.

Aquí hay un desorden típico:

• Una sola tabla como user_orders que mezcla info del usuario, campos de facturación, dirección de envío, totales del pedido y estado de pago.
• users.last_order_id apunta a orders.id, mientras orders.user_id apunta a users.id.
• orders.payment_id apunta a payments.id, pero payments.order_id también apunta a orders.id.

Ese conjunto crea dos problemas a la vez.

Primero, obtienes dependencias circulares: no puedes insertar un order sin un payment, y no puedes insertar un payment sin un order, así que la app usa filas temporales o secuencias de actualización raras.

Segundo, la tabla está sobrecargada: cada actualización al email o dirección de un usuario corre el riesgo de reescribir orders antiguos (o dejar orders inconsistentes).

Un rediseño más limpio suele ser una división más propiedad clara:

• users posee identidad (email de login, nombre, IDs de auth).
• addresses es propiedad de users (muchas direcciones por usuario).
• orders es propiedad de users (un usuario tiene muchos orders).
• order_items es propiedad de orders (un order tiene muchos items).
• payments es propiedad de orders (un order puede tener uno o varios intentos de pago).

Ahora el flujo de inserción es simple: crear el order, añadir items y luego crear un intento de pago. No hay IDs de marcador de posición ni last_order_id necesario porque “último order” es una consulta.

En términos de código de la app, las consultas quedan más claras: el checkout deja de hacer actualizaciones cruzadas para mantener todo en sincronía y el historial de pedidos se convierte en un join directo de users a orders a items.

Errores comunes que empeoran el desastre

La forma más rápida de quedar atascado otra vez es “limpiar” el esquema sin un plan de cómo mover la app y los datos con ello. La mayoría de fallos no son por habilidades SQL. Ocurren porque los cambios pequeños se extienden a jobs, informes y casos borde que nadie recordó.

Cambios que parecen ordenados pero crean roturas

Un error clásico es dividir una tabla porque parece demasiado grande y luego poner en producción las tablas nuevas sin un plan de migración. Si las tablas vieja y nueva se escriben durante un tiempo, obtienes deriva de datos: dos fuentes de la verdad que nunca coinciden. La app parece bien hasta que un reembolso, un caso de soporte o un informe mensual expone la discrepancia.

Otro problema común es eliminar columnas demasiado pronto. Jobs en background, exports, dashboards y pantallas admin suelen depender de campos legacy mucho después de que el código principal deje de usarlos. Borrarlos antes de tener un inventario completo convierte una limpieza en un incidente en producción.

Otros errores que empeoran las cosas de forma recurrente:

• Añadir más campos “type” (user_type, order_type, entity_type) en lugar de modelar relaciones reales con tablas claras y foreign keys.
• Ignorar constraints y confiar solo en el código de la app, lo que permite que entren datos malos durante imports, scripts, reintentos o futuras features.
• Renombrar conceptos (“customer” a “account”) sin acordar definiciones, de modo que distintos equipos usan la misma palabra para significar cosas diferentes.

Un ejemplo rápido de cómo sale mal

Imagina una users sobrecargada que también guarda campos de facturación, membresía en orgs e info de leads. Alguien la divide en users, customers y leads, pero no backfill de forma consistente y no deja claro cuál tabla posee el email. Ahora dos tablas aceptan actualizaciones del mismo email y las herramientas de soporte leen la equivocada. El esquema parece más limpio en papel, pero la propiedad quedó menos clara.

Una mentalidad más segura: trata los cambios de esquema como cambios de producto. Haz la propiedad explícita, añade constraints temprano, migra datos en pasos y mantiene los campos viejos hasta tener pruebas de que nadie depende de ellos.

Lista rápida y pasos prácticos siguientes

Cuando un esquema se siente enredado, no necesitas una reescritura grande para avanzar. Empieza con un conjunto corto de comprobaciones que muestren de dónde viene la confusión y luego elige una refactorización pequeña que puedas terminar con seguridad.

Comprobaciones rápidas (encuentra el desorden)

Busca los patrones que crean relaciones espagueti rápido:

• Enlaces circulares: la tabla A depende de B, B depende de C y C depende de A (a menudo a través de tablas auxiliares).
• Conceptos duplicados: la misma cosa del mundo real almacenada en varios lugares (por ejemplo, customer_id y buyer_id con la misma intención).
• Tablas sobrecargadas: una tabla haciendo muchos trabajos (orders + payments + envío + notas de soporte juntos).
• Fuente de la verdad confusa: dos tablas reclaman propiedad (por ejemplo, tanto users como accounts guardan email y estado).
• Constraints débiles: faltan foreign keys, constraints únicas y columnas que permiten “cualquier cosa” que ocultan errores.

Después de detectar uno o dos de estos, elige un área (por ejemplo, pagos o identidad de usuario) y trátala como un mini-proyecto.

Comprobaciones de seguridad (no pierdas datos)

Antes de cambiar la estructura, planifica cómo probarás que no rompiste nada:

• Haz una copia de seguridad y confirma que puedes restaurarla.
• Escribe un plan de rollback para cada cambio (aunque sea “mantener columnas viejas hasta verificar”).
• Backfill en pasos: crea campos o tablas nuevas primero, copia datos, cambia lecturas y luego escrituras.
• Verifica después del backfill: conteos de filas, sumas y comprobaciones sobre registros reales (incluyendo casos borde).
• Añade monitorización básica: vigila la tasa de errores y consultas fallidas durante la ventana de despliegue.

La mantenibilidad proviene de decisiones pequeñas y claras. Da a cada tabla un único propietario (el hogar de ese concepto), elige nombres consistentes y aplica reglas con constraints para que los problemas fallen pronto en lugar de propagarse silenciosamente.

Si estás tratando con una app rota generada por IA y el esquema sigue oponiéndose, trata el código y el esquema como un mismo sistema. Refactoriza un flujo de trabajo de extremo a extremo (esquema + consultas + tests) y luego pasa al siguiente.

Si quieres una segunda opinión rápida antes de reescribir grandes partes, FixMyMess en fixmymess.ai ofrece auditorías de código gratuitas para codebases generadas por IA y ayuda a remediar problemas como esquemas enredados, lógica rota y brechas de seguridad, normalmente en 48–72 horas.