Tu base de datos funciona. Eso no significa que esté bien.

Hay una frase que escucho seguido cuando llego a un proyecto:

"La base de datos siempre ha funcionado así."

Y casi siempre es cierta. El sistema responde, los usuarios trabajan, nadie se queja. Pero cuando empiezo a explorar las tablas, los stored procedures, las columnas sin documentar — la historia que encuentro es otra.

Este artículo es sobre algo que tiene nombre técnico pero que en la práctica se ve muy concreto: database sprawl y schema pollution. Dos problemas que no explotan de un día para otro, sino que se acumulan durante años hasta que alguien necesita hacer un cambio importante y descubre que no puede.

---

Cómo empieza todo (y por qué nadie lo detiene)

El patrón es siempre el mismo.

Una empresa tiene un sistema core — puede ser un ERP, un CRM, un software especializado de su industria. Funciona bien. Pero el negocio crece, aparecen necesidades nuevas, y alguien del equipo de desarrollo dice: "Es más rápido agregar una columna aquí que construir un módulo nuevo."

Y tiene razón. En ese momento, es más rápido.

Entonces agregan la columna. Después otra. Luego una tabla entera para guardar algo que "no encajaba" en la estructura original. Crean un stored procedure de 800 líneas que nadie quiere tocar porque "si funciona no lo muevas". Agregan una columna llamada , luego , y eventualmente .

Nadie está haciendo nada malo intencionalmente. Son decisiones razonables, una por una. El problema es que nadie está viendo el conjunto.

Cinco años después, la base de datos tiene:

• Tablas del sistema original mezcladas con tablas custom sin ninguna convención de nombres
• Columnas que nadie sabe para qué sirven porque el developer que las creó ya no está
• Stored procedures que llaman a otros stored procedures que llaman a vistas que dependen de tablas que quizás ya no se usan
• Datos duplicados en tres lugares distintos porque cada módulo nuevo resolvió el mismo problema por separado
• Cero documentación

Eso es database sprawl: la base de datos creció sin control, en todas las direcciones, sin un plan. Y schema pollution: el esquema original — el que diseñó el producto o sistema que compraron — quedó contaminado con lógica de negocio propia, columnas ajenas, y dependencias que el proveedor nunca contempló.

---

El costo real que nadie calcula

Aquí está el problema con estos dos fenómenos: no duelen hasta que necesitas hacer algo importante.

El sistema del día a día sigue funcionando. Las consultas responden (aunque sean lentas, ya te acostumbraste). Los reportes salen (aunque tarden, ya es normal).

Pero llega el momento en que necesitas:

• Actualizar el sistema core a una versión nueva — y no puedes, porque tu customización rompió el esquema original de formas que el proveedor no soporta
• Migrar a la nube — y no sabes qué tablas son críticas, cuáles están obsoletas, y qué va a romper si mueves solo una parte
• Conectar una herramienta nueva — un CRM, un BI, una integración con otro sistema — y el modelo de datos es tan inconsistente que nadie puede mapearlo limpiamente
• Escalar — y las queries que funcionaban con 50,000 registros se caen con 500,000

He visto empresas pagando decenas de miles de dólares al año en soporte de un software que nunca pudieron actualizar porque la base de datos estaba tan modificada que el proveedor se negó a garantizar el upgrade. Literalmente pagando por algo que no podían usar.

Ese es el costo de no ver el problema hasta que es demasiado tarde.

---

Cómo identificar si tienes este problema

No necesitas una auditoría formal para sospechar. Estas son las señales:

Señal 1: Nadie sabe qué hace cierta tabla o columna Si tienes que buscar al developer más antiguo del equipo para entender qué es , ya tienes un problema. Señal 2: Los stored procedures tienen más de 300 líneas Un stored procedure largo no es malo por definición. Pero si tiene 800 líneas, sin comentarios, con lógica de negocio mezclada con transformaciones de datos y validaciones — eso es una bomba de tiempo que nadie quiere desarmar. Señal 3: Tienes columnas tipo

,

,

Esas columnas aparecen cuando alguien necesitaba guardar algo y no quería crear una tabla nueva. Después de varios años, nadie recuerda qué guardaba cada una. Señal 4: No puedes hacer un upgrade del sistema sin miedo Si la respuesta a "¿cuándo actualizamos la versión?" es "mejor no tocamos nada", la base de datos es probablemente parte del problema. Señal 5: Los reportes tardan y ya lo normalizaste Una query que tarda 15 segundos no es normal. Es una señal de que algo en el esquema, los índices, o el volumen de datos está mal dimensionado.

---

Qué se puede hacer (y qué no)

Lo primero que hay que entender es que no existe una solución mágica. Database sprawl se construye durante años y no se resuelve en un sprint.

Lo que sí se puede hacer:

Auditoría antes que cualquier otra cosa. Antes de tocar nada, necesitas entender qué tienes. Qué tablas existen, cuáles se usan realmente (muchas veces hay tablas con cero registros en producción que nadie eliminó), cuáles tienen dependencias críticas. Separar lo que es del sistema y lo que es tuyo. Si estás usando un software de terceros y le agregaste tablas propias, esas tablas deberían vivir en un esquema separado con una convención clara. del sistema original vs de tu módulo. Esto solo ya facilita enormemente cualquier upgrade futuro. Documentar mientras operas, no después. La documentación que se promete "para después" nunca llega. Cada vez que alguien entiende para qué sirve una tabla o columna misteriosa, ese conocimiento tiene que quedar escrito en ese momento. No agregar más sin un estándar. Si el equipo de desarrollo no tiene una convención para nombrar tablas, columnas, índices y procedimientos, cada developer va a inventar la suya. Con el tiempo, la base de datos parece hecha por cinco personas distintas que nunca se hablaron. Porque lo fue. Evaluar el costo de limpiar vs el costo de no limpiar. A veces la deuda técnica de una base de datos es tan grande que lo más sensato es planificar una migración limpia en lugar de intentar arreglar lo que hay. No es la respuesta que nadie quiere escuchar, pero es la honesta.

---

Un prompt para auditar tu base de datos con IA

Esto no reemplaza una auditoría real — una IA no puede conectarse a tu base de datos y revisar millones de registros. Pero sí puede ayudarte a estructurar el análisis, identificar patrones problemáticos, y generar preguntas que hacerle a tu equipo.

Copia este prompt y pégalo en Claude, ChatGPT o el modelo que uses. Reemplaza las secciones entre corchetes con la información real de tu sistema:

Con los resultados de ese prompt ya tienes un punto de partida concreto para hablar con tu equipo o con alguien externo que pueda ayudarte.

---

Lo que llevo viendo años

Las empresas que tienen este problema no son descuidadas ni incompetentes. Son empresas que crecieron, que tomaron decisiones pragmáticas bajo presión, y que nunca tuvieron el espacio para detenerse y ver el cuadro completo.

El sistema funciona. Eso es real. Pero "funciona" y "está en condiciones de soportar lo que viene" son dos cosas muy distintas.

Si tienes la sospecha de que tu base de datos tiene años de decisiones acumuladas sin revisar, probablemente estés en lo correcto. La pregunta no es si el problema existe — es cuándo vas a necesitar resolverlo.

Mejor que sea antes de que no tengas opción.

---

¿Estás en medio de una situación así? Puedo ayudarte a hacer la auditoría y entender qué tienes antes de tomar cualquier decisión. Hablemos.