Comment effectuer des procédures de stockage de version efficaces?

Question

Je fais partie de l'équipe de développement de base de données qui travaille pour le grand eshop. Nous utilisons MS SQL 2016 et ASP.NET. SQL Server est utilisé par les clients de plus de 10 serveurs IIS utilisant le pooling de connexions (nous avons environ 7-10k batch/sec) dans l'environnement de production et nous utilisons 18 serveurs DEV/TESTING IIS (mais seulement une base de données DEV). Nous développons une nouvelle fonctionnalité qui nous oblige à apporter des modifications aux procédures stockées existantes assez souvent.

Si nous déployons une modification dans un environnement de production, cela fait partie de la modification de la modification de l'application pour IIS et de la modification des procédures de base de données. Lors du déploiement, ils sont toujours modifiés à 5 serveurs IIS, puis à 5 serveurs de plus en plus. En attendant, les versions anciennes et nouvelles existent sur les serveurs IIS. Ces versions doivent coexister pendant un certain temps tout en utilisant les procédures de la base de données en même temps. Au niveau de la base de données, nous résolvons cette situation en utilisant plusieurs versions de la procédure. L'ancienne version de l'application appelle EXEC dbo.GetProduct, la nouvelle version de l'application utilise dbo.GetProduct_v2. Après avoir déployé une nouvelle version de l'application sur tous les services Internet (IIS), tout le monde utilise dbo.GetProduct_v2. Lors du prochain déploiement, la situation sera inversée et dbo.GetProduct contiendra une nouvelle version. Une situation similaire se trouve dans l'environnement de développement et de test. Je réalise pleinement que cette solution n'est pas idéale et je voudrais être inspiré.

Nous considérons séparer la partie de données et la partie logique. Dans une base de données, il y aura des tables de données, d'autres ne contiendront que des procédures et d'autres objets de programme. Lors du déploiement d'une nouvelle version, nous déployons simplement une nouvelle version de la base de données entière contenant la logique et n'aurons pas besoin de créer une version de la procédure. Les procédures de la base de données logique interrogeront la base de données avec des données. Cependant, l'inconvénient de cette solution est l'impossibilité d'utiliser des procédures compilées en mode natif que nous prévoyons d'utiliser l'année prochaine car elles ne prennent pas en charge l'interrogation dans d'autres bases de données.

Une autre option utilise une base de données et les versions de procédures distinctes dans différents schémas ...

Si vous avez des idées, des avantages/inconvénients ou vous savez des outils qui peuvent nous aider et gérer/deploy/utiliser plusieurs versions proc , s'il vous plaît faire un commentaire.

Merci beaucoup

Edit: Nous utilisons TFS et Git, mais cela ne résout pas le versioning des procédures dans la base de données SQL. Ma question principale est de savoir comment gérer la nécessité de gérer plusieurs versions d'applications IIS en utilisant plusieurs versions des procédures dans la base de données.

Answer 1

La gestion des versions est facile avec SSDT ou SQL Compare et le contrôle de source. Ainsi sont les déploiements.

Votre problème ne concerne pas la version.

Vous avez besoin de deux procédures stockées différentes avec le même nom, probablement les mêmes paramètres mais un code différent et peut-être des résultats différents. C'est plus réalisable dans, disons, le code .net, car vous pouvez utiliser la surcharge à un point.

Votre problème est déploiements utilisant échelonné code différent:
Deux versions du même proc doit coexister.

Dans votre cas, j'utiliserais des synonymes pour masquer le nom réel de la procédure stockée.

Vous avez donc ces procédures stockées.

• dbo.GetProduct_v20170926 (dernière version)
• dbo.GetProduct_v20171012 (cette version)
• dbo.GetProduct_v20171025 (prochaine version)
• dbo.GetProduct_v20171113 (un après)

Ensuite, vous avez

CREATE SYNONYMN dbo.GetProductBlue FOR dbo.GetProduct_v20171012; 
CREATE SYNONYMN dbo.GetProductGreen FOR dbo.GetProduct_v20170926; 

Vous r progressivement les déploiements IIS font référence à l'un des SYNONYMNs

de la prochaine version ...

DROP SYNONYMN dbo.GetProductBlue; 
CREATE SYNONYMN dbo.GetProductBlue FOR dbo.GetProduct_v20171025; 

puis

DROP SYNONYMN dbo.GetProductGreen; 
CREATE SYNONYMN dbo.GetProductGreen FOR dbo.GetProduct_v20171113; 

L'utilisation d'un autre schéma est le même résultat, mais vous finirais avec

- Blue.GetProduct 
- Green.GetProduct 

Ou codez votre date de publication dans le nom du schéma.

- Codev20171025.GetProduct 
- Codev20171113.GetProduct 

Vous auriez le même problème, même vous aviez un autre ensemble de serveurs IIS et maintenir une base de code sur chaque ensemble de serveurs:

sur la base blue/green deployment model

Answer 2

A hypothèses de couple.

• Vous avez un numéro de version dans votre code IIS quelque part - peut-être un fichier App.config ou Web.config et que le numéro de version peuvent être référencées dans votre code .NET
• Votre but est de ne pas changer votre IIS les noms .NET SP sur chaque version, mais l'ont appelé la version correcte du SP dans le DB
• Toutes les versions du SP prendre les mêmes paramètres
• version différente de la SP peut retourner des résultats différents

Ul timidement il n'y a aucun moyen d'avoir plusieurs versions de la procédure stockée dans la base de données. L'idée est d'abstraire cela, autant que possible, de IIS (je suppose). En fonction de ce qui précède, je pense que vous pourriez ajouter un autre paramètre à votre SP qui accepte un numéro de version (que vous obtiendriez probablement de Web.config dans IIS).

Ensuite, votre procédure stockée dbo.GetProduct devient une procédure stockée "contrôleur" ou "routage" dont le seul but est de prendre le numéro de version et de transmettre les paramètres restants au SP sous-jacent approprié.

Donc vous auriez 1 SP par version (utilisez la convention de nommage que vous souhaitez). Et dbo.GetProduct appellerait le approprié en fonction du numéro de version transmis. Un exemple est ci-dessous.

create proc dbo.GetProduct_v1 @Param1 int, @Param2 int 
as 
begin 
    --do whatever is needed for v1 
    select 1 
end 

go 

create proc dbo.GetProduct_v2 @Param1 int, @Param2 int 
as 
begin 
    --do whatever is needed for v2 
    select 2 
end 

go 

create proc dbo.GetProduct @VersionNumber int, @Param1 int, @Param2 int 
as 
begin 
    if @VersionNumber = 1 
    begin 
     exec dbo.GetProduct_v1 @Param1, @Param2 
    end 

    if @VersionNumber = 2 
    begin 
     exec dbo.GetProduct_v2 @Param1, @Param2 
    end 
end 

Une autre pensée serait de construire dynamiquement votre nom de SP dans IIS (basé sur le numéro de version dans Web.config) au lieu de coder en dur le nom de SP.