Cross Database SQL Scripts

Question

Je travaille sur un projet où nous parlons directement d'une base de données à une autre. Nous avons une base de données maîtresse dans laquelle le client met à jour son site Web, puis les modifications sont transférées d'une base de données à l'autre via de nombreux scripts SQL. La base de données master fonctionne comme un site de prévisualisation leur permettant de voir les changements avant de les pousser à vivre.

Actuellement, nous codons le nom de la base de données esclave directement dans les requêtes SQL.

par exemple. INSERT INTO [esclave-base de données] .dbo.TableName

Ceci est une douleur absolue cependant lors de la reprise du développement où nous aurons plusieurs ensembles de deux bases de données. Tous les proc mémorisés pertinents pour le développement en cours sont mis à jour pour pointer vers la base de données esclave pour cette branche particulière, par ex. [branche5-slave-database]. Ceci n'est pas idéal car les modifications doivent ensuite être modifiées manuellement lors de l'insertion dans le coffre (en changeant les noms de base de données codés en dur).

Y a-t-il une meilleure façon de procéder? La seule solution que je puisse voir pour le moment serait de créer une instance SQL Server pour chaque branche, ce qui signifierait que les noms de bases de données peuvent toujours rester identiques dans toutes les branches. Ce serait une douleur absolue et aurait un frais généraux. Est-il possible de définir une constante pour le nom de la base de données dans SQL Server? Nous permettant de mettre à jour une seule valeur sur les bases de données de la branche. Le SQL dynamique est hors de question.

Answer 1

Jetez un oeil à l'aide du système sans papier procédure stockée sp_MSforeachdb

sp_MSforeachdb

Il vous permet de traiter le code contre chaque base de données au sein de l'instance actuelle. Vous pouvez explicitement exclure la base de données du système.

Answer 2

Certains dialectes de SGBD permettent d'ouvrir des bases de données avec un alias de base de données au moment de la connexion. Cela vous offre les mêmes flexibilités que les tables dans les alias ou les alias de colonnes dans d'autres parties de SQL.

Dans ce cas, vous pouvez établir une connexion avec l'alias de base de données "slave", quelle que soit la chaîne de connexion réelle. Ensuite, vous ne devrez pas coder les noms de base de données esclaves réels dans les requêtes. Vous devrez toutefois gérer successivement l'ouverture et la fermeture de différents esclaves afin d'éviter une collision dans le nom "esclave". Une autre alternative est d'utiliser des liens de table, si votre dialecte les prend en charge. Vous devrez faire face à un problème similaire en évitant les collisions.

Answer 3

Vous pouvez utiliser SQL dynamique pour modifier le nom de la base de données esclave. Par exemple:

declare @query nvarchar(4000) 
set @query = 'INSERT INTO [' + @slavedbname + '].dbo.TableName ...' 
exec sp_executesql @query 

Vous pouvez enregistrer le nom de l'esclave DB dans une table et le récupérer à partir de là:

select @slavedbname = value from Settings where name = 'SlaveDbName' 

Ou vous pourriez avoir une convention où il est égal à la base de données actuelle plus _slave:

select @slavedbname = db_name() + '_slave' 

Answer 4

Sorte d'dynamiquement en utilisant SQL généré (comme l'indique @Andomar), il n'y a aucun moyen de paramétrage d'un nom de base de données lors de l'exécution en SQL.

Cependant, lorsque vous exécutez le DDL pour construire la base de données, vous avez beaucoup plus d'options. Le plus simple est probablement d'utiliser la syntaxe du paramètre SQLCmd, en fournissant le nom de la base de données esclave en tant qu'argument lorsque vous exécutez le script de génération (voir le SQLCmd doco). Cela pourrait alors être incorporé dans votre script de build/deploy, donc faire une construction de schéma pour un environnement donné pourrait être facilement automatisé. J'ai fait exactement cela dans le passé pour à peu près le scénario que vous décrivez. En fin de compte, la meilleure solution consiste peut-être à supprimer totalement la migration du contenu de la base de données et à la placer dans la couche d'application. Cette approche est généralement plus propre et entraîne des avantages supplémentaires car l'emplacement des deux bases de données cesse d'avoir de l'importance (elles peuvent être sur des serveurs distincts par exemple). Vous seul pouvez décider si cela est trop pour vos besoins.