Discussion :

[nicodn02]

Bonjour,

Je suis actuellement confronté à un problème d'automatisation de déploiement de scripts SQL.
Contexte :
- Le déploiement des scripts SQL est réalisé via DbUp (.NET).
- Un même applicatif .NET est déployé à 2 reprises (multi marques) sur 2 instances de BDD différentes (par exemple une instance en France et une instance au Québec).
- Le métier est écrit dans les procédures stockées
- Des spécificités propres à chaque marque est écrite dans les procédures stockées : actuellement le contenu d'une procédure stockée peut être différent d'une instance/marque à l'autre
- Certaines procédures stockées font appelles à des serveurs liés lors de certaines jointures, noms des serveurs liés étant différents d'une instance/marque à l'autre

Actuellement, nous passons un temps "fou" pour pouvoir déployer et maintenir ces 2 instances de base de données avec leur spécificité. Nous souhaitons automatiser un maximum le déployer de ses scripts.

Ma question :
Comment gérer les spécificités de chaque marque dans les procédures stockées (@@servername like '%marque1%, @@servername like '%marque2%') sachant que l'on utilise des serveurs liés (le serveur lié doit exister pour que la procédure stockée compile) ?

Merci par avance.

Nicolas

[Michel.Priori]

Ma question :
Comment gérer les spécificités de chaque marque dans les procédures stockées (@@servername like '%marque1%, @@servername like '%marque2%') sachant que l'on utilise des serveurs liés (le serveur lié doit exister pour que la procédure stockée compile) ?

Pas tout compris.
Tu voudrais faire une "super" procédure stockée qui exécute la procédure de telle ou telle instance en donnant comme paramètre le nom du serveur lié en plus des paramètres d’exécution ?

[nicodn02]

Pour schématiser :

2 instances de BDD : marque1 et marque2
dans marque1, nous avons un serveur lié marque1_serv_1
dans marque2, nous avons un serveur lié marque2_serv_2

sachant que c'est le même applicatif web (a quelques if près dans le code) entre marque 1 et marque2, l'objectif étant de rapprocher au maximum le schéma de marque1 et marque2 ainsi que les procédures stockées

Il existe une procédure stocker rechercher_client() qui dans marque1 fait une jointure sur les serveurs liés marque1_serv_1 mais dans marque2, cette même procédure stockée doit faire une jointure sur marque2_serv_2

Donc soit je pourrais faire, dans rechercher_client()
if (@@servername = marque1)
begin
exec rechercher_client_marque1()
end
elsif (@@servername = marque2)
begin
exec rechercher_client_marque2()
end

Cependant, cela m'oblige à trouver comment déployer rechercher_client_marque1() uniquement sur marque1 et idem pour recherche_client_marque2 sur marque2; sachant que bien sûr, pour des raisons de RGPD, marque1 ne peut pas enregistré le serveur lié marque2_serv_2 et inversement

[Michel.Priori]

Et les synonymes ?
Chaque instance aura ses propres synonymes pour l'ensemble des tables à utiliser.

Un script qui en fonction de l'instance créera ce qui doit être référencé (local vs distant)

Une bonne convention de nommage là dessus et le tour est joué

[Michel.Priori]

sachant que bien sûr, pour des raisons de RGPD, marque1 ne peut pas enregistré le serveur lié marque2_serv_2 et inversement

t'as lu ça où ?

[aieeeuuuuu]

bonjour

une solution pourrait être de créer des synonymes, ayant le même nom sur tous les serveurs, mais pointant sur la table de marque1_serv_1 pour le marque 1 et sur la table de marque2_serv_2 pour le marque 2.

ainsi, le code de votre procédure reste le même ensuite pour les deux serveurs


[edit] grillé , j'aurai dû rafraichir la page avant de poster !

[nicodn02]

La solution des synonymes avaient été envisagées mais en cible, nous avons beaucoup de procédures stockées qui font appellent à plusieurs tables/vues sur les serveurs liés et du coup on se retrouverait avec beaucoup de synonymes; mais il faut finalement peut être que j'en passe par là.

[Michel.Priori]

Si on ne peut résoudre le volume des objets, une bonne stratégie de gestion de l'espace de nom devient la meilleure approche.

La solution de créer des schémas est la seule option que je connaisse sous SQL server.

Un seul niveau c'est court.

Dommage que SSMS ne permette pas d'afficher par schéma, un peu comme sous Oracle.
J'ai testé un add-in qui fait apparaitre les schémas à l'intérieur des nœuds de l'arborescence SQL mais c'est pas performant car c'est une surcouche qui attend d'avoir la liste de tous les objets dans l'interface avant de peupler les sous nœuds.
Quand t'as des milliers d'objets c'est long. trop long.