Cómo integrar varias bases de datos dentro de una empresa

Introducción

Una empresa puede empezar con una única base de datos y terminar utilizando varias sin haberlo planificado expresamente. Una aplicación comercial mantiene clientes y oportunidades, otra conserva facturación, un sistema técnico registra incidencias, una aplicación propia necesita su propio esquema y una herramienta analítica almacena información preparada para informes. Cada base puede funcionar correctamente por separado y, aun así, el conjunto producir problemas cuando los procesos necesitan compartir información.

El reto no consiste simplemente en conseguir que una base “vea” a otra. Integrar varias bases de datos dentro de una empresa significa establecer mecanismos controlados para relacionar, mover o consultar información entre sistemas sin perder autoridad, identidad, trazabilidad ni capacidad de recuperación. Una integración técnicamente rápida puede crear dependencias difíciles de mantener si nadie sabe qué sistema manda sobre cada dato, qué ocurre cuando dos bases discrepan o cómo se recupera una sincronización interrumpida.

La necesidad aparece con frecuencia cuando una misma entidad existe en varios sistemas. Un cliente puede tener un identificador en la aplicación comercial, otro en facturación y otro en soporte. Un producto puede cambiar de nombre en una base y conservar una descripción antigua en otra. Una operación puede considerarse completada en un sistema mientras el proceso que debía transmitirla al siguiente falla silenciosamente.

Por eso, integrar bases de datos no debe empezar por elegir una herramienta. Primero hay que decidir qué información necesita circular, qué sistema es autoritativo para cada dato, qué nivel de consistencia necesita el proceso, qué retraso es tolerable y qué ocurre cuando una parte de la integración deja de estar disponible.

Este artículo desarrolla un método práctico para construir esa arquitectura de integración: inventariar bases y dominios, definir fuentes de verdad, relacionar identificadores, elegir entre acceso directo, APIs, sincronización, replicación, ETL o captura de cambios, controlar transformaciones y conflictos, proteger credenciales, monitorizar el flujo y diseñar recuperación. El objetivo es que varias bases puedan colaborar sin convertirse en una red opaca de dependencias.

Índice

• Qué significa integrar varias bases de datos
• Qué decidir antes de conectar nada
• Crear un inventario de bases y responsabilidades
• Separar dominios de información
• Definir fuentes de verdad
• Relacionar identificadores entre sistemas
• Principales patrones de integración
• Acceso directo entre bases
• Integración mediante APIs o servicios
• Replicación
• ETL y ELT
• Captura de cambios
• Integración mediante eventos
• Sincronización unidireccional y bidireccional
• Elegir el nivel de consistencia necesario
• Resolver conflictos entre bases
• Normalizar y transformar datos
• Mantener históricos y trazabilidad
• Seguridad y mínimo privilegio
• Evitar impacto sobre producción
• Diseñar tratamiento de errores y reintentos
• Monitorizar la integración
• Preparar recuperación y reconstrucción
• Documentar contratos y dependencias
• Integrar motores diferentes
• Usar la integración como etapa de migración
• Plan práctico de implantación
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué significa integrar varias bases de datos

Integrar no es necesariamente fusionar. Dos bases pueden seguir siendo independientes y colaborar mediante intercambios controlados. La arquitectura correcta depende de qué necesita hacer la empresa con los datos.

Las necesidades más habituales son:

• consultar información de varias bases en un mismo proceso;
• copiar determinados datos de una base a otra;
• mantener una réplica para lectura;
• consolidar información para reporting;
• propagar cambios entre aplicaciones;
• alimentar una base analítica;
• migrar progresivamente de un sistema a otro;
• mantener sincronizados catálogos o entidades compartidas.

Estas situaciones pueden parecer equivalentes, pero no lo son. Copiar datos una vez al día para construir un informe tiene requisitos muy distintos de sincronizar el estado de un pedido en segundos.

Integración lógica frente a unificación física

Una empresa puede conseguir una visión integrada sin mover todos los datos a una única base. De hecho, mantener varios dominios separados suele ser más sostenible cuando cada aplicación tiene necesidades distintas.

Este enfoque se relaciona con cómo convertir la base de datos en el núcleo del sistema de información: la clave no es concentrar todo físicamente, sino saber dónde vive cada verdad y cómo circula.

Qué decidir antes de conectar nada

Antes de elegir tecnología conviene responder cinco preguntas.

Qué dato necesita compartirse

No hay que integrar tablas completas por defecto. Puede bastar con unos pocos campos.

Quién es autoritativo

Debe saberse qué sistema puede modificar oficialmente cada dato.

Qué retraso es aceptable

¿El dato debe aparecer en segundos, minutos, horas o al día siguiente?

Qué ocurre si falla la integración

¿El proceso puede continuar? ¿Se acumulan cambios? ¿Hace falta intervención manual?

Qué nivel de coherencia se necesita

Una cifra de reporting puede tolerar retraso. Un pago confirmado quizá no.

Estas respuestas determinan la arquitectura más que el motor utilizado.

Crear un inventario de bases y responsabilidades

El primer paso técnico es saber qué bases existen realmente.

Para cada una conviene registrar:

• nombre;
• motor;
• versión;
• entorno;
• aplicación responsable;
• entidades principales;
• criticidad;
• identificadores clave;
• ritmo de actualización;
• volumen aproximado;
• consumidores actuales;
• métodos de acceso disponibles.

Detectar integraciones informales

A veces ya existe integración sin llamarla así: exportaciones CSV, consultas manuales, hojas intermedias, scripts cron o copias de tablas.

Esas piezas deben formar parte del inventario porque pueden ser dependencias reales.

Identificar datos repetidos

Clientes, productos, estados, proveedores o referencias pueden aparecer en varias bases. Esta repetición no es necesariamente un problema si está gobernada; el problema es no saber cuál manda.

Separar dominios de información

Antes de conectar tablas conviene identificar dominios empresariales.

Ejemplos:

• clientes;
• ventas;
• facturación;
• soporte;
• productos;
• inventario;
• proyectos;
• identidades;
• analítica.

Una base puede contener más de un dominio, pero entenderlos ayuda a decidir qué datos cruzan fronteras.

Evitar compartir tablas internas sin necesidad

Una aplicación puede tener decenas de tablas técnicas que ninguna otra debería conocer. La integración debería exponer conceptos útiles, no detalles accidentales de implementación.

Diseñar límites

Si el dominio de facturación es responsable de facturas, otras bases deberían recibir los datos necesarios sin convertirse en editores alternativos de esa información.

Definir fuentes de verdad

Cuando una misma entidad aparece en varias bases, debe existir una regla de autoridad.

La fuente de verdad puede variar por atributo

Una base puede ser autoritativa para la identidad del cliente y otra para sus datos fiscales. No siempre existe una única autoridad para toda la entidad.

Evitar edición circular

Si dos bases pueden modificar libremente el mismo campo y reenviárselo mutuamente, aparecen conflictos y bucles.

Este principio ya aparece en cómo integrar múltiples fuentes de datos sin crear caos operativo, pero aquí se aplica específicamente a bases que deben intercambiar registros de forma técnica y repetible.

Relacionar identificadores entre sistemas

Una integración fiable necesita reconocer que dos registros representan la misma entidad.

Identificador común

La opción más sencilla es compartir un identificador empresarial estable.

cliente_id = 58321

Tabla de correspondencias

Cuando cada sistema ya tiene su propio ID, puede mantenerse una relación:

cliente_global_id | sistema       | id_local
58321              | ventas        | 8841
58321              | facturacion   | 22019
58321              | soporte       | 7120

No unir únicamente por nombre

Nombres, direcciones y descripciones pueden cambiar o repetirse.

Correo electrónico como identificador

Puede ser útil en algunos dominios, pero no es universal: cambia, puede compartirse y puede estar ausente.

Conservar IDs de origen

Cuando se importan datos, mantener el identificador del sistema origen facilita reconciliación y trazabilidad.

Principales patrones de integración

No existe un único método correcto. Las opciones más habituales son:

• acceso directo entre bases;
• APIs o servicios;
• replicación;
• ETL o ELT;
• captura de cambios;
• eventos y colas;
• exportaciones periódicas.

La selección depende de latencia, volumen, criticidad, autonomía de sistemas y capacidad técnica.

Acceso directo entre bases

En algunos entornos una aplicación o proceso puede consultar directamente otra base.

Ventajas

• sencillez inicial;
• pocos componentes;
• consultas flexibles;
• latencia baja.

Riesgos

• acoplamiento al esquema interno;
• permisos excesivos;
• rotura ante cambios de tablas;
• carga imprevisible;
• dependencia de disponibilidad simultánea.

Cuándo puede ser razonable

En entornos pequeños, controlados y con pocos consumidores, especialmente para lectura.

Preferir vistas estables

Una vista de solo lectura puede ofrecer un contrato más estable que permitir acceso a todas las tablas.

Integración mediante APIs o servicios

Una API permite que cada sistema conserve el control de su modelo interno.

En lugar de consultar tablas directamente:

GET /clientes/58321
GET /facturas/2026-00481

Ventajas

• desacoplamiento;
• validación;
• control de permisos;
• contratos versionables;
• trazabilidad.

Costes

• más desarrollo;
• otro componente que operar;
• latencia adicional;
• gestión de errores HTTP y disponibilidad.

Las APIs son especialmente útiles cuando una base pertenece claramente a una aplicación y no se quiere exponer su esquema interno.

Replicación

La replicación copia cambios de una base o instancia a otra manteniendo una relación continua.

Réplica de lectura

Puede descargar reporting o consultas pesadas del sistema principal.

Replicación lógica

Algunos motores permiten seleccionar tablas o conjuntos de cambios en lugar de copiar la instancia completa.

Replicación no equivale a integración empresarial

Una réplica reproduce datos, pero no decide qué sistema es autoritativo ni resuelve diferencias semánticas entre modelos.

Tampoco sustituye a un backup

Un borrado erróneo puede replicarse inmediatamente.

ETL y ELT

ETL significa extraer, transformar y cargar. ELT cambia el orden para cargar primero y transformar después.

Cuándo encaja bien

• reporting;
• consolidación nocturna;
• data warehouse;
• integración histórica;
• migraciones;
• procesos donde unos minutos u horas de retraso son aceptables.

Separar datos brutos y transformados

Conservar una capa de origen puede ayudar a reproducir transformaciones.

Registrar cada carga

Conviene saber:

• cuándo empezó;
• cuándo terminó;
• qué rango procesó;
• cuántos registros leyó;
• cuántos escribió;
• qué errores produjo.

Captura de cambios

La captura de cambios, o CDC, permite detectar inserciones, actualizaciones y borrados producidos en una base para transmitirlos a otros sistemas.

Ventaja principal

Evita releer continuamente tablas completas para saber qué cambió.

Casos de uso

• sincronización casi en tiempo real;
• alimentación analítica;
• migraciones progresivas;
• propagación de eventos.

Complejidad

Exige controlar orden, reintentos, cambios de esquema y posición dentro del log de transacciones.

No adoptarlo solo por modernidad

Para una integración diaria de pocos miles de filas, una extracción incremental simple puede ser más mantenible.

Integración mediante eventos

En lugar de copiar tablas, un sistema puede publicar que algo ocurrió:

cliente_creado
pedido_confirmado
factura_pagada
incidencia_cerrada

Otros sistemas reaccionan a esos eventos.

Ventajas

• reduce acoplamiento;
• permite consumidores independientes;
• favorece procesamiento asíncrono.

Retos

• duplicados;
• orden;
• reintentos;
• eventos perdidos;
• versionado del mensaje;
• observabilidad.

Los eventos deben tener identificadores y diseñarse para que repetirlos sea seguro.

Sincronización unidireccional y bidireccional

Unidireccional

Los cambios fluyen desde un sistema maestro hacia uno o varios consumidores.

Base maestra → Base A
             → Base B

Es más fácil de razonar y suele ser preferible.

Bidireccional

Ambas bases pueden producir cambios que deben reconciliarse.

Esto exige reglas de conflicto:

• qué campo puede modificar cada sistema;
• qué cambio tiene prioridad;
• cómo se compara la versión;
• qué ocurre con actualizaciones simultáneas.

Evitar bidireccionalidad por comodidad

Muchas veces puede rediseñarse el flujo para que cada atributo tenga una autoridad clara.

Elegir el nivel de consistencia necesario

No todos los procesos requieren que todas las bases reflejen el mismo dato exactamente al mismo instante.

Consistencia inmediata

Puede ser necesaria en operaciones críticas estrechamente acopladas.

Consistencia eventual

Permite que un sistema reciba el cambio segundos o minutos después.

Puede ser suficiente para:

• reporting;
• catálogos;
• analítica;
• notificaciones;
• índices de búsqueda.

Definir SLA de integración

En lugar de decir “sincronizado”, conviene definir algo medible: “los cambios deben propagarse en menos de cinco minutos”.

Resolver conflictos entre bases

Los conflictos aparecen cuando dos sistemas contienen valores distintos para un mismo dato.

Prioridad por fuente

El sistema autoritativo gana.

Prioridad por campo

Facturación puede mandar sobre NIF y CRM sobre estado comercial.

Versión

Puede utilizarse un número de versión o timestamp, aunque “el último cambio gana” no siempre es correcto desde el punto de vista empresarial.

Revisión manual

Algunos conflictos no deberían resolverse automáticamente.

Registrar el conflicto

Debe conservarse suficiente contexto para entender:

• registro;
• origen;
• valor A;
• valor B;
• regla aplicada;
• resultado.

Normalizar y transformar datos

Dos bases pueden representar el mismo concepto de forma diferente.

Ejemplos:

• fechas en distintas zonas horarias;
• país mediante código o texto;
• estados con vocabularios diferentes;
• importes con distinta precisión;
• nombres de productos distintos;
• booleanos representados como 0/1 o true/false.

Transformación explícita

Las reglas deberían estar documentadas y versionadas.

No ocultar pérdida de información

Si un sistema tiene diez estados y otro solo cuatro, la transformación debe definir qué ocurre con el detalle.

Separar dato original y normalizado

En procesos analíticos puede ser útil conservar ambos.

Mantener históricos y trazabilidad

Una integración no debería borrar el rastro de cómo llegó un dato.

Campos útiles pueden ser:

source_system
source_id
imported_at
source_updated_at
integration_run_id

Histórico de sincronización

Permite reconstruir qué lote produjo un cambio.

Evitar sobreescribir sin contexto

Si un dato crítico cambia, puede ser útil conservar valor anterior y origen.

Trazabilidad para depuración

Cuando un informe muestra un dato incorrecto, hay que poder seguirlo hasta la fuente.

Seguridad y mínimo privilegio

Integrar bases crea nuevos caminos de acceso.

Una cuenta por integración

Facilita auditoría y revocación.

Solo lectura cuando sea suficiente

Una extracción analítica no necesita permiso de escritura.

Limitar tablas o vistas

No toda integración necesita acceso al esquema completo.

Proteger credenciales

Las claves no deben quedar embebidas en scripts o repositorios.

Cifrar conexiones

Especialmente cuando cruzan redes no confiables.

Minimizar datos

No copies campos sensibles si el sistema destino no los necesita.

Evitar impacto sobre producción

Una integración puede convertirse en una carga inesperada.

No leer tablas completas continuamente

Utiliza filtros incrementales, índices o CDC cuando el volumen lo justifique.

Programar cargas pesadas

Los procesos nocturnos pueden evitar competir con usuarios, siempre que exista una ventana real.

Utilizar réplicas para lectura

Cuando los informes generan mucha carga, una réplica puede proteger producción.

Controlar conexiones

Un pool mal configurado puede abrir demasiadas sesiones.

Medir

La integración debería formar parte de la observabilidad de la base. Si el problema está en el motor, puede complementarse con cómo monitorizar bases de datos de forma sencilla.

Diseñar tratamiento de errores y reintentos

Las integraciones fallan. La diferencia entre una arquitectura robusta y una frágil es cómo se comporta cuando eso ocurre.

Errores temporales

Timeouts, caída de red o servicio no disponible pueden reintentarse.

Errores de datos

Un identificador desconocido o un formato inválido puede necesitar revisión.

Reintentos limitados

Evita bucles infinitos.

Idempotencia

Repetir una operación no debería crear duplicados.

Dead letter o cola de excepciones

Los registros que no pueden procesarse deben quedar visibles para revisión.

Monitorizar la integración

No basta con monitorizar cada base por separado. Hay que vigilar el flujo entre ellas.

Métricas útiles:

• última sincronización correcta;
• registros procesados;
• registros fallidos;
• retraso de sincronización;
• duración;
• reintentos;
• cola pendiente;
• edad del elemento más antiguo;
• diferencias de conteo cuando sean significativas.

Detectar ausencia

Una integración puede dejar de ejecutarse sin producir error. La antigüedad del último éxito es una señal fundamental.

Correlación

Un identificador de ejecución permite relacionar logs de origen y destino.

Preparar recuperación y reconstrucción

Una integración debe poder reconstruirse después de un fallo.

Definir punto de reanudación

Puede ser:

• timestamp;
• ID incremental;
• posición de log;
• evento;
• lote.

Conservar datos suficientes para reprocesar

Si un lote falla, debe ser posible repetirlo sin depender de datos temporales ya eliminados.

No usar la réplica como único respaldo

La política de recuperación de cada base sigue siendo independiente.

Reconstrucción completa

Conviene saber si el destino puede regenerarse desde origen o si contiene datos propios que también necesitan backup.

Documentar contratos y dependencias

Cada integración debería tener una ficha breve.

La documentación debe explicar el contrato, no duplicar todo el código.

Integrar motores diferentes

Es posible integrar PostgreSQL, MariaDB, SQL Server, SQLite u otros motores, pero aparecen diferencias.

Tipos de datos

Decimales, fechas, booleanos o JSON pueden comportarse de manera distinta.

Codificación

Debe controlarse Unicode y collation.

Semántica SQL

Funciones, identificadores y sintaxis no siempre son equivalentes.

Transacciones

Coordinar una única transacción entre motores independientes puede resultar complejo. Muchas arquitecturas prefieren consistencia eventual y compensación.

Herramientas intermedias

ETL, APIs o eventos suelen desacoplar mejor sistemas heterogéneos que intentar ejecutar consultas distribuidas complejas.

Usar la integración como etapa de migración

Integrar dos bases puede ser una fase temporal mientras se sustituye un sistema.

Sincronización inicial

Se copia histórico.

Doble convivencia

Durante un periodo ambos sistemas permanecen activos.

Propagación de cambios

Se sincronizan nuevas operaciones.

Cambio de autoridad

En un punto planificado, el nuevo sistema pasa a ser maestro.

Retirada

Se verifica que no quedan consumidores del sistema antiguo antes de apagarlo.

Esta estrategia necesita especialmente una autoridad clara para evitar que ambos sistemas compitan durante la transición.

Plan práctico de implantación

1. Inventariar las bases

Identifica motores, aplicaciones, dominios y responsables.

2. Elegir un proceso concreto

No intentes integrar toda la empresa de una vez.

3. Definir fuente de verdad

Decide qué sistema manda para los datos implicados.

4. Identificar claves

Define cómo relacionar registros.

5. Establecer latencia

Decide cuánto retraso puede tolerarse.

6. Elegir patrón

API, ETL, réplica, CDC, evento o acceso controlado.

7. Diseñar transformaciones

Documenta formatos y vocabularios.

8. Crear permisos mínimos

Una identidad técnica específica.

9. Probar con datos reales representativos

Incluye duplicados, faltantes y casos límite.

10. Diseñar reintentos

Haz que las operaciones sean idempotentes.

11. Añadir monitorización

Mide éxito, errores, retraso y acumulación.

12. Documentar recuperación

Define cómo reprocesar desde un punto conocido.

13. Activar progresivamente

Empieza con un subconjunto y aumenta alcance después de validar.

Errores frecuentes

Integrar tablas completas sin necesidad

Aumenta acoplamiento y exposición.

No definir fuente de verdad

Dos sistemas empiezan a competir por el mismo dato.

Relacionar por nombre

Produce asociaciones ambiguas.

Crear sincronización bidireccional por defecto

Multiplica conflictos.

Usar una cuenta administrativa

Da a la integración más poder del necesario.

No medir retraso

Una integración puede “funcionar” pero llegar horas tarde.

No diseñar idempotencia

Los reintentos generan duplicados.

Ocultar errores

Los registros fallidos deben quedar visibles.

Cargar producción con consultas masivas

El reporting puede perjudicar la operación.

Confundir replicación con backup

Los errores también se replican.

No documentar transformaciones

Con el tiempo nadie sabe por qué los valores cambian.

No preparar cambios de esquema

Una columna renombrada puede romper el flujo.

Crear demasiadas cadenas

A → B → C → D dificulta conocer el origen real del dato.

Integrar todo porque es posible

Cada enlace añade operación y mantenimiento. Solo debe existir si resuelve una necesidad real.

Lista de comprobación

• ¿están inventariadas las bases implicadas?
• ¿se conoce la finalidad del flujo?
• ¿está definida la fuente de verdad?
• ¿cada entidad tiene un identificador estable?
• ¿se conoce la dirección del intercambio?
• ¿está definida la latencia aceptable?
• ¿se ha elegido el patrón más simple que cumple el requisito?
• ¿las transformaciones están documentadas?
• ¿se sabe cómo resolver conflictos?
• ¿la integración tiene una cuenta específica?
• ¿los permisos son mínimos?
• ¿las conexiones están protegidas?
• ¿se ha evaluado el impacto sobre producción?
• ¿los reintentos son limitados?
• ¿las operaciones son idempotentes?
• ¿los errores quedan visibles?
• ¿se mide la última sincronización correcta?
• ¿se mide el retraso?
• ¿existe un identificador de ejecución?
• ¿se puede reprocesar un lote?
• ¿se conoce el punto de reanudación?
• ¿los cambios de esquema se coordinan?
• ¿la integración está documentada?
• ¿cada base mantiene su propia estrategia de recuperación?

Preguntas frecuentes

Conclusión

Integrar varias bases de datos dentro de una empresa no consiste en construir el mayor número posible de conexiones entre sistemas. Consiste en crear flujos de información deliberados, con una autoridad clara y un comportamiento previsible cuando todo funciona y cuando algo falla.

El punto de partida es el inventario: qué bases existen, qué dominios representan, qué aplicaciones dependen de ellas y qué información necesita compartirse. Después debe definirse una fuente de verdad para cada dato relevante y una forma estable de relacionar identidades entre sistemas.

La tecnología puede adoptar muchas formas. El acceso directo puede ser suficiente en un entorno pequeño; una API aporta desacoplamiento; la replicación ayuda a separar lecturas; ETL y ELT encajan bien en consolidación y analítica; la captura de cambios y los eventos permiten reducir latencia cuando existe una necesidad real. Ningún patrón es superior en todos los casos.

La arquitectura más sostenible suele ser la que utiliza el mecanismo más simple capaz de cumplir los requisitos de consistencia, latencia, seguridad y recuperación. Añadir componentes sin necesidad aumenta la superficie de fallo y el coste de operación.

Una integración fiable también debe asumir que habrá errores. Reintentos, idempotencia, colas de excepciones, trazabilidad, métricas y puntos de reanudación deben diseñarse desde el principio. La pregunta no es si un enlace fallará alguna vez, sino si el sistema sabrá detectar el fallo y continuar sin corromper datos.

La seguridad requiere cuentas específicas, mínimo privilegio y minimización de información. El rendimiento exige evitar lecturas masivas innecesarias y separar cargas cuando corresponda. La documentación debe conservar contratos, transformaciones, fuentes de verdad y procedimientos de recuperación.

Cuando estas piezas están claras, varias bases pueden seguir siendo autónomas y, al mismo tiempo, formar parte de un sistema de información coherente. La empresa deja de depender de copias manuales y coincidencias ambiguas, y gana una arquitectura en la que cada dato tiene origen, destino, identidad y reglas de circulación comprensibles.