En primer lugar, desde el punto de vista arquitectónico, sería bastante desconfiado con cualquier diseño que implicara extraer datos a través de múltiples enlaces de bases de datos. Lo he visto hacer cuando la fuente final es una versión antigua de Oracle a la que la base de datos de destino no puede conectarse directamente, por lo que se usó una base de datos intermedia que ejecuta una versión intermedia de Oracle. Sin embargo, eso es muy raro en la práctica.
Desde una perspectiva de rendimiento, este tipo de enfoque es gravemente problemático. Por supuesto, existe el problema de que los datos se enviarán dos veces a través de la red. Pero lo que es más preocupante, está tomando un problema difícil, optimizando las declaraciones de SQL distribuidas y haciéndolo casi intratable. Básicamente, tendría que garantizar que nunca consultaría datos locales y datos remotos en la misma consulta o tendría que vivir con el rendimiento resultante si Oracle decide un plan de consulta estúpido porque queda el conjunto de herramientas para permitirle optimizar este tipo de consulta es mínimo.
Dicho esto, la base de datos intermedia necesitaría tener sinónimos o vistas que abstraigan el enlace de la base de datos. Entonces
En A:
- crear enlace de base de datos a B
En B:
- crear enlace de base de datos a C
- crear una
tablede sinónimos para[email protected]
En A, puedes
SELECT *
FROM [email protected]
