Discussion :

[Mandotnet]

Bonjour,

Je dispose d'un référentiel de client sous la forme d'une base de donnée.
J'aimerai savoir comment je pourrai exploiter ces informations dans une autre application métier.

Je pourrai par exemple juste récupérer L'ID du client et le copier dans ma BDD concernant mon appli métier, mais niveau intégrité relationnelle ce n'est pas top.

Que me conseillez-vous de faire ? Merci pour votre aide.

Pour information, mes SGBD sont SQL Server 2000 et 2005

[cinemania]

Quel miracle... sous SQL Server a partir de la version 2000 il est possible de lier les serveurs pour les interconnecter.

Dès lors que deux SGBDR SQL Server sont reliés pour ton code SQL/.NET embarqué, tout ce passe comme si les deux étaient sur la meme machine... la seule différence c'est qu'il faudra donner un chemin complet (pas oublier le nom du serveur avant le nom de base de données) si tu accède a une ressource sur un autre serveur.

Ensuite je ne vois vraiment pas ton problème, tu as une BD avec une collection de client définis dans plusieurs tables.

Quelque soit l'application qui veut y accèder elle peut y accèder... suffit de bien règler les droits d'accès... Ensuite il existe une chose magnifique en SQL pour les bases de données relationnelles, on appel ça les FOREIGN KEYS...
Ca permet de conserver l'intégrité relationnelle et référencielle.

Dans ta BDD "métier" rien ne t'interdit de faire référence a une ID client. Si tu défini la colonne concernée comme étant une FOREIGN KEY vers la BDD "clients".
Le mécanisme des FOREIGN KEYS imposera un minimum de cohérence dans tes accès aux données et imposera un minimum d'intégrité relationnel et référenciel.

Sinon je vois vraiment pas où se situe ton problème...
Si ca n'a pas répondu a ta question... reexplique en soyant plus clair... en définissant "mieux" ton besoin, et en agrémentant d'exemples... ca aidera.

[Mandotnet]

Bonjour et merci d'avoir répondu à mon message.

tu dis :

Dans ta BDD "métier" rien ne t'interdit de faire référence a une ID client. Si tu défini la colonne concernée comme étant une FOREIGN KEY vers la BDD "clients"...

C'est exactement ce que je veux faire ! Mais autant pour deux tables d'une même BDD ça va tout seul, pour deux tables de deux BDD différentes ça ne me parait pas faisable à ma connaissance, comment fais tu?

Actuellement j'étudie une solution basé sur de la réplication en local, mais ça me parait être l'artillerie lourde pour pas grand chose...

Plus généralement, cela pose un problème d'architecture quant à la capitalisation des données car je me rétrouve de plus en plus avec des applications qui utilisent des doublons de données ...

[cinemania]

Effectivement après avoir testé...

Les clés étrangères dans des bases de données "croisées" ne sont pas prises en charge sous sql server.

Cependant une autre chose existe... LES TRIGGERS.
Si SQL ne peut garantir l'intégrité référencielle pour toi, les Triggers le peuvent... eux.

Pour cela plusieurs voies, mais globallement ca ressemble à cela.

BDD [clientele]
table [clients] => trigger sur la suppression: cli_delete

BDD [utilisation_clientele]
table [truc] =>
- trigger sur l'insertion: truc_insert
- trigger sur la modification: truc_modify

Alors... comment ca marche... c'est très simple.

pour cli_delete tu as deux voies:
1. tu vérifie que [truc].[client] ne fait pu référence à [clients].[id] que tu veux supprimer. Si tu trouve une référence... tu fait un rollback du lot.
2. tu vérifie que [truc].[client] fait référence, si t'en trouve, tu les vires... et tu valide le lot.

pour truc_insert : tu verifie que l'entrée choisie "existe" dans la table distante.
si oui tu commit, sinon tu rollback

pour truc_modify : tu vérifie la meme contrainte que pour truc_insert.

C'est un peu long surtout qu'il faut vérifier cette même contrainte sur toutes les tables utilisatrices, mais ca marche...
sinon tu peux faire un MIX.

tu créer une table de duplication dans la base utilisatrice pour bénéficier des foreign keys dans ta base utilisatrice.
et tu dispose les triggers insert, delete, modify sur [clients]
qui assure la cohérence et l'exactitude des DEUX TABLES
ou tu les répliques, mais la réplication peut poser des problemes, surtout à cause des contraintes d'intégrité imposer sur la seconde (l'esclave)