Consulta a dos databases diferentes....
 

:confused: ....buscando y buscando no encuentro la forma de hacerlo. (es mas, casi aseguraria que no se va a poder hacer) :confused:

Imaginemos un database en local y otro database en remoto.

Como se puede hacer en una consulta para extraer algunos datos de una tabla que cuelga del primer database relacionados con una tabla que cuelga del otro database.

Buffff...que mal me he explicado.

Ejemplo:
Database1 apunta a 192.168.1.2:c:\bdd\pruebaLocal.gdb
Pongamos que tiene una tabla llamada mitablaLocal

Database2 apunta a 192.168.1.3:c:\bdd\pruebaRemoto.gdb
Pongamos que tiene una tabla llamada mitablaRemoto

Si se pudiera hacer algo de la forma:

select database1.mitablalocal.campo1 from database1.mitablalocal where
database1.mitablalocal.campo1 not in (select database2.mitablaremoto.campo1 from database2.mitablaremoto)

Como veis busco una solucion facil para sincronizaciones entre bdd's diferentes.

Gracias por adelantado.... ;)

Espero vuestas respuestas, aunque sea para decir que no se puede hacer.

Hola,

pues tú mismo te has contestado. El motor de consutas InterBase (o Firebird) no permite enlazar objetos de diferentes bases de datos.

Algunas bibliotecas de componentes (caso del BDE) permiten (yo nunca lo he probado) hacer el truco de lanzar consultas que involucren a bases de datos distintas, aunque imagino que internamente debe lanzar diferentes consultas (una para cada base de datos) y después construir un único Dataset con los resultados obtenidos por cada una de ellas.

Saludos.

P.D. Creo recordar que en el foro ya hablamos otra vez sobre este tema.

Gracias por contestar, si que me suena de otras veces haber leido algo sobre sincronizaciones en el foro, pero con tanto cambio de versiones de motores de bdd y tal como avanzan las cosas, igual me habia perdido algo.

Seguiremos haciendolo de forma "pedreste" y rudimentaria, una pena, algo que se hubiera podido hacer con una consulta a mi me lleva muchas lineas de codigo.

Habia oido que MiSQL ya tenia solucionado este problema.

Salu2

;)

no sé si SQL Server lo permite (seguramente sí). De todas formas, es discutible que el asunto sea realmente una deficiencia del servidor y no un problema de diseño de la base de datos. Vamos, que la teoría relacional establece relaciones entre relaciones (tablas), pero no entre bases de datos.

Saludos.

Según entiendo, txemag se refería a mySQL y no a SQL Server.

De hecho, este tipo de consultas son soportadas por varios motores. Yo se de mySQL y de Oracle.

Totalmente de acuerdo, aunque tarde o temprano, firebird terminará por soportarlo, pues es un hecho que se llega el momento en que es necesario interconectar diferentes bases de datos, ya sea a nivel de consulta, o a nivel de actualización. NO he profundizado en el tema en firebird, pero tengo entendido que si tiene soporte para commit en 2 fases... que es la base de las transacciones distribuidas.

Lo que para mi representa una deficiencia también en interbase (y no se si firebird siga la misma línea) es el hecho que no pueden haber dos tablas con el mismo nombre, de diferentes propietarios... esto en mas de una ocasión, obliga a dividir en varias bases de datos, lo que podria estar en una sola, con esquemas identicos bajo diferentes owners.

Para txemag, queda como tarea, verificar su modelo y determinar si no hay que unificar ambas bases de datos en una... si es asi, podes valerte de varios mecanismos para voltear la información de una base en otra y a partir de alli replantear tus consultas.

Hasta luego.

;)

Hola Juan Antonio,

Gracias por el apunte. Estaba con un navegador que no visualiza bien la tipografía y creí leer que se refería SQL Server.

Sí, estoy de acuerdo, aunque, como dije antes, es discutible, ya que lo que puedes hacer con dos bases de datos lo puedes hacer con una. Es una cuestión de diseño. Evidentemente, siempre puede haber algún caso marginal que no se ajuste a esto.

Correcto, pero el problema de txemag no es la capacidad multi-base de datos de las transacciones InterBase (que sí las soporta), sino las consultas multi-base de datos, y ésas, por ahora, no puede con ellas.

Saludos.

No sé si Oracle o SQL Server lo permitan pero ciertamente MySql no permite hacer lo que requiere txemag. MySql permite consultas entre distintas bases de datos en un mismo servidor más no entre distintos servidores.

Por otra parte no estoy muy seguro que la necesidad de consultar distintas bases de datos sea una cuestión de mal diseño de la base. Doy un ejemplo simplificado: en una facultad se tienen sistemas para control escolar y para nomina. Ambos sistemas son totalmente independientes en naturaleza, diseñados y mantenidos por equipos distintos. Pero algunas tablas, como la de profesores es común a ambas y sería deseable contar con una única copia. No creo que un buen diseño relacional consista en fusionar en una sóla base de datos las de ambos sistemas.

// Saludos

:o :o no habia caido en cuenta del detalle... tenes toda la razón. Oracle si lo permite aunque el otro servidor esté del otro lado del mundo, media vez esté en línea...

Esto depende de las características y de las "tradiciones" de la base de datos con la que se trabaje. Al menos en oracle, es muy común (aunque no es una regla) tener una sola instancia de la base de datos corriendo, con diferentes esquemas para soportar los diferentes sistemas que se almacenan en un servidor... el mecanismo de permisos (grant/revoke, roles, etc) permite un control espectácular sobre lo que un esquema permitirá hacer a otros sobre sus propios objetos. Asi, un sistema de control escolar será un esquema, y la nómina otro esquema en una misma base de datos. Entiendo que en interbase/firebird, sea mas normal es que se trate de bases de datos distintas.

Hasta luego.
;)

Esto lo entiendo, pero justamente son eso, tradiciones y capacidades mas no una cuestión de buen o malo diseño relacional.

// Saludos

Hola,

te cito de nuevo: "son totalmente independientes en naturaleza"

Si esto es así, ser totalmente independientes, por qué habría de relacionar relaciones (tablas) de una base de datos y de la otra.

Si existen relaciones que son comunes, es que ambos sistemas no son totalmente independientes.

Insisto en mi comentario, y especialmente para el caso que presentas como ejemplo: el modelo de datos debería diseñarse dentro de una sola base de datos. El modelo de datos no se ve afectado (o no debería) por el número de equipos que diseñen y mantengan ese modelo.

Por otro lado, el modelo relacional tiene su nivel de abstracción máximo en la base de datos, no en conjuntos de bases de datos. Es decir, no contempla las relaciones entre diferentes bases de datos. Por tanto, sí es un problema de diseño que tengas que relacionar una tabla de una base de datos con otra tabla de otra base de datos. Otro asunto distinto es que sea más sencillo diseñar y mantener el sistema en bases de datos separadas, pero es un artificio de conveniencia.

Saludos.

Cierto, pero yo dije independientes en naturaleza. Una cosa es que compartan algunos datos y otra que formen parte del mismo sistema o modelo relacional. Vayamos un poco más lejos. La dependencia donde trabajo se encarga de cursos de lenguas extranjeras que se imparten a cualquier estudiante o trabajador de la universidad. Para efectos de validación de datos debemos trabajar con copias de las tablas de trabajadores y de estudiantes de toda la universidad. Cada tabla proviene de Departamentos distintos, el de Personal y el de Administración Escolar (de toda la universidad) y sería muy deseable que en lugar de trabajar con copias pudiésemos simplemente consultar las correspondientes tablas de los otras Departamentos. Siendo que cada facultad o dependencia cuenta con sus propios trabajadores y estudiantes y que éstos son parte del conjunto total universitario de trabajadores y de estudiantes, tendríamos que definir un único sistema universitario que englobe a todos los subsistemas aun cuando cada uno de ellos tengan muy poco que ver unos con los otros salvo por unos cuantos datos comunes. Esto es, a mi juicio, absolutamente impensable e innecesario. Siguiendo así tendríamos entonces que diseñar el Gran Modelo Relacional, padre de todos los modelos relacionales en donde se incluya al mundo entero.

A mi entender el modelo relacional habla de relaciones entre entidades. Cómo se acomoden estas entidades es ya otro punto.

// Saludos

Hola,

Estás mezclando conceptos. Una cosa es la abstracción que nos permite describir una parcela del mundo real (sea ésta físico o no) y que puede llegar al nivel de detalle que sea necesario, y otra el modelo de datos (caso del modelo relacional) que describe el modo como representamos esa abstracción. Una misma abstracción puede ser respresentada por diferentes modelos de datos, p. ej. a través del modelo relacional o un modelo jerárquico, pero la abstracción del mundo real sigue siendo la misma, no se define en función del modelo de datos elegido.

Evidentemente, es tu punto de vista. Desde el punto de vista de Edgar Codd, el padre del modelo relacional, no es así. Revisa las 12 normas de Codd para que un sistema sea considerado como relacional, y comprobarás que el asunto que aquí se debate, la necesidad de relacionar relaciones (tablas) de bases de datos distintas, no es objeto de discusión.

Saludos.

Realmente no veo qué tiene que ver esto con la posible violación al modelo relacional por el hecho de consultar base de datos distintas.

Las normas a que te refieres son las normas para una base de datos relacional, es decir, una base de datos que se ajusta al modelo relacional, pero el modelo relacional ni siquiera habla de bases de datos como tal. En su trabajo original Codd habla simplemente de relaciones entre entidades mediante el uso de las relaciones en el sentdo matemático.

Pues creo que está claro. Tú has indicado la necesidad de ir subiendo el nivel de abstracción de lo que tratas de modelizar para que concuerde con tu idea de que es necesario tener diferentes bases de datos porque al diseñador o al administrador del sistema le sea más cómodo de manejar. Y lo que yo he tratado de decir es que el modelo (de datos) no es el que fija el nivel de esa abstracción.

Las doce normas son posteriores al trabajo original de Codd en la ACM (anterior a la existencia de ningún motor de datos que pudiera denominarse como relacional), y precisamente las propuso para, una vez que ya existían motores de datos que se autodenominaban relacionales, poder determinar que características debían tener para ser considerados como tales. Y sí, allí ya se habla de bases de datos (relacionales).

Insisto, el modelo relacional no recoge en ningún caso (al menos que yo recuerde) la necesidad de relacionar diferentes bases de datos. Su tope máximo son las relaciones de relaciones (tablas) - A tener en cuenta la diferencia en Inglés entre relation y relationship.

Saludos.