Consulta a dos databases diferentes....

[kinobi]

Empezado por txemag

Habia oido que MiSQL ya tenia solucionado este problema.

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.

[jachguate]

Empezado por kinobi

no sé si SQL Server

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.

Empezado por kinobi

es discutible que el asunto sea realmente una deficiencia del servidor y no un problema de diseño de la base de datos

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.

[kinobi]

Hola Juan Antonio,

Empezado por jachguate

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

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

Empezado por jachguate

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.

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.

Empezado por jachguate

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.

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.

[roman]

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

[jachguate]

Empezado por roman

MySql permite consultas entre distintas bases de datos en un mismo servidor más no entre distintos servidores.

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...

Empezado por roman

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.

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.

[roman]

Empezado por jachguate

Esto depende de las características y de las "tradiciones" de la base de datos con la que se trabaje.

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

// Saludos

[kinobi]

Hola,

Empezado por roman

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,

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.

Empezado por roman

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.

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.

[roman]

Empezado por kinobi

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

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.

Empezado por kinobi

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.

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

// Saludos

[kinobi]

Hola,

Empezado por roman

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.

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.

Empezado por roman

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

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.