Utiliser plusieurs sources de données

[iNCiTE Web]

Bonjour

Je me tourne vers vous pour recherche un début de solution...

Actuellement une application Windows (VB) manipule simultanément des données provenant :

• d'une base Access locale
  
• d'une base externe (peut importe laquelle, ça peut être MySQL comme Oracle ou même Hyperfile voire un CSV, par l'ODBC qui va bien)
  

Pour cela on utilise le principe des "tables liées" (propre à Access je pense) : dans Access il est créé une table virtuelle, qui est en fait une liaison avec la base externe (peu importe laquelle puisque par ODBC donc)

Le but étant de comparer les données de 2 tables (schémas identiques bien sûr) et ne ressortir que les enregistrements présentant une différence, en une seule requête et en ne parcourant pas toutes les données.

Aujourd'hui ça fonctionne parfaitement, puisque du coup on fait un SELECT entre 2 tables de la même source de données (Access et la table liée).

La question est : comment reproduire ce fonctionnement en se passant d'Access, peu importe le langage, peu importe le SGBD ?

Exemple : mon application (Delphi, .net, Windev, PHP...) doit faire une requête dans 2 tables situées dans 2 SBGD différents...

Merci de m'éclairer ou m'orienter vers un équivalent...

[jcaron]

"peu importe le langage, peu importe le SGBD" c'est assez restrictif, et ça implique presque forcément d'avoir un agent intermédiaire entre l'application et les bases de données qui fasse apparaître les deux bases comme une seule, avec beaucoup d'intelligence puisqu'il faut que cet agent soit capable d'interpréter et d'exécuter ces requêtes SQL en faisant de façon cachée d'autres requêtes SQL vers les bases d'origine.

Ca veut dire qu'en gros cet agent a de fortes chances d'être lui-même un SGBD qui a la faculté de pouvoir consulter des bases externes comme c'est le cas dans ton exemple. Note qu'en général ce genre d'accès externe est nettement moins performant qu'une base locale, parce que le SGBD "interrogateur" a beaucoup moins de contrôle et de visibilité sur la base distante. Quand tu dis "en une seule requête et en ne parcourant pas toutes les données" c'est la vision par l'appli, ce n'est pas réellement ce qui se passe en interne.

Quelle est la contrainte qui t'oblige à changer le système existant? VB? Tu dois pouvoir utiliser n'importe quel autre langage qui peut appeler une base via ODBC (et va donc faire les requêtes dans Access comme le fait VB). Access? Tu peux utiliser une autre base de données avec le même type de fonctionalités. Je n'ai aucune idée de si ça existe ou pas sur mysql, mais il me semble que c'est possible avec Postgresql (mais c'est probablement un module additionel).

D'autres possibilités:

- de faire les deux accès directement dans l'appli, et de faire les comparaisons à cet endroit (si c'est bien fait, la charge de travail est la même, elle est juste déplacée)

- de copier les données d'une base dans l'autre (probablement via une appli externe qui va faire les deux accès) et ensuite faire une comparaison entre deux tables "locales"

Mais si tu nous dis quelle est ta contrainte ça nous aidera probablement...

Jacques.

[iNCiTE Web]

"peu importe le langage, peu importe le SGBD" c'est assez restrictif, et ça implique presque forcément d'avoir un agent intermédiaire entre l'application et les bases de données qui fasse apparaître les deux bases comme une seule, avec beaucoup d'intelligence puisqu'il faut que cet agent soit capable d'interpréter et d'exécuter ces requêtes SQL en faisant de façon cachée d'autres requêtes SQL vers les bases d'origine.

Oui c'est possible, mais un nanard comme Access sait le faire

Ca veut dire qu'en gros cet agent a de fortes chances d'être lui-même un SGBD qui a la faculté de pouvoir consulter des bases externes comme c'est le cas dans ton exemple. Note qu'en général ce genre d'accès externe est nettement moins performant qu'une base locale, parce que le SGBD "interrogateur" a beaucoup moins de contrôle et de visibilité sur la base distante. Quand tu dis "en une seule requête et en ne parcourant pas toutes les données" c'est la vision par l'appli, ce n'est pas réellement ce qui se passe en interne.

On a la main sur notre base locale, elle sera sûrement gérée en natif par le langage (comme Access avec VB aujourd'hui), la base externe n'est pas de notre fait, et selon le client elle peut être comme je le disais MySQL Oracle Informix Fichiers libres etc

Quelle est la contrainte qui t'oblige à changer le système existant? VB?

VB6 et Access 97 ne s'installent plus sur du 64-bits

Tu dois pouvoir utiliser n'importe quel autre langage qui peut appeler une base via ODBC (et va donc faire les requêtes dans Access comme le fait VB). Access? Tu peux utiliser une autre base de données avec le même type de fonctionalités. Je n'ai aucune idée de si ça existe ou pas sur mysql, mais il me semble que c'est possible avec Postgresql (mais c'est probablement un module additionel).

Peu importe si c'est un module additionnel, l'idée étant que ça fonctionne

D'autres possibilités:

- de faire les deux accès directement dans l'appli, et de faire les comparaisons à cet endroit (si c'est bien fait, la charge de travail est la même, elle est juste déplacée)

- de copier les données d'une base dans l'autre (probablement via une appli externe qui va faire les deux accès) et ensuite faire une comparaison entre deux tables "locales"

Non car dans les 2 cas il faut rapatrier la totalité des enregistrements de la base externe, et ça c'est à exclure.

Aujourd'hui l'appli fonctionne mais doit être ré-écrite.

Et on ne trouve pas de système pour permettre de faire l'équivalent.

Par exemple en ASP.net si j'ai bien lu, on peut avoir un truc du genre :

db1 = connexion1.labase

db2 = connexion2.labase

SELECT champ1 FROM db2.table JOIN db1.table ON db2.table.id = db1.table WHERE db1.champ <> db2.champ