Discussion :

[David.V]

Bonjour, sur nos applications actuels, nous utilisons aujourd'hui sur notre serveur un certains nombre de bases fixes (que j'appellerais A, B et C pour l'exemple). Certainnes procédures stockées nécessitent de ramener des données d'une base à l'autre du style

depuis le serveur B :
SELECT * FROM A.DBO.Table1

Nous envisageons de rendre nos applications "multi base", c'est à dire qu'au lieu d'avoir un serveur avec uniquement les bases A, B, et C, nous aurions pour chaque client, une copie de ces bases sous la forme A1, B1 et C1 pour pour le client 1, et ainsi de suite.

Le problème, ce sont ces appels inter base dans certainnes des procédures stockées. Est-ce qu'il existe un moyen de ne pas avoir en dur dans le script le nom de serveur que l'on référence ? J'ai envie de dire que non pour ma part aprés les recherches que j'ai faite, mais je préfère avoir d'autre avis.

Merci d'avance pour toute suggestion utile

Edit : je n'avais pas précisé qu'il ne faut pas non plus passer par une requête dynamique, c'est difficilement envisageable de ré-écrire toutes les procédures qui utilisent des appels inter base.

[serge0934]

je comprend pas où est le pb ?
tu peux créer la base A sur le serveur1 et sur le serveur2, il suffit que ton appli "tapes" dans le bon serveur.ex:

serveur1 => base A,B,C
serveur2 => base A,B,C
etc...

[David.V]

Le problème est de faire du "multi base" sur le même serveur. Sur différent serveur, ça ne pose pas de problème en effet. Mais sur un seul serveur ?

[serge0934]

il te suffit de créer une instance par "poste" => cela équivaut a faire x serveurs sur le même

[WOLO Laurent]

Le seul soucis pour ta méthode c'est la contre performance puis que la seule solution c'est de passer par le sql dynamique.

[kagemaru]

sous sql 2005 il y aurait 2 moyens :

avec les schema (tu peux alors avoir 2 objets avec le même nom dans une même base ex :

A.client1.table
A.client2.table
...

et en fonction du login utilisé, le schema par défaut est client1 ou client2 etc.

par contre il te faut un login par client.
------------------
si tu dois absolument garder 3 base par client (arf !) tu peux toujours tenter l'aventure des synonymes (un beau tas de spaghettis en perspective ...)

tu créés une base D (donc une 4ième base) par client dans laquelle seront stockés les synonymes qui pointeront vers les objets répartis dans les 3 autre s bases A, B, C.

ex :
D1.dbo.factures -> A1.dbo.factures
D1.dbo.histo -> B1.dbo.histo
D2.dbo.factures -> A2.dbo.factures
D2.dbo.commandes -> C2.dbo.commandes
...
ce qui fait que tu peux garder le même code dans tes procs (qui n'accéderont qu'aux objets de la base Dx) quel que soit ton client... mais bon ça fait peur comme soluce.

Pourquoi ne pas tout stocker dans une seule base ?