Modifications de version pour les procédures stockées

Question

J'ai une application qui repose très fortement sur les procédures stockées (SQL 2005/2008). Nous effectuons une mise à jour mineure qui modifiera 25 à 35 de ces procédures stockées. L'application est telle que les deux versions de la procédure stockée doivent être disponibles.

Ceci est la version majeure 4 de l'application et généralement, nous avons été en mesure de modifier complètement la structure de données pour aller avec chaque nouvelle version. Cependant, dans ce cas, nous ne pouvons pas faire cela.

Voici mes 2 options que je suis venu avec

1. faire une version "2" de chaque procédure stockée. Si j'avais une procédure appelée getUser, créez un getUser2. L'inconvénient de ceci est que le nombre de procédures stockées augmentera exponentiellement avec chaque changement de version

2. Ajoutez un paramètre @version à chaque procédure stockée par défaut à v1. Cela permettrait de réduire le nombre de procédures stockées mais gonflerait chaque procédure stockée

Quelqu'un a des commentaires à ce sujet? D'autres idées intelligentes?

Cody

Answer 1

Je ne crée pas deux fichiers différents qui est sûr. Peut-être que dans votre contrôle source, vous devriez créer une branche de toutes vos versions, puis une nouvelle branche avec votre prochaine version, puis vous pouvez inclure les deux branches en tant que dossiers distincts sur votre système et faire pointer votre logique métier sur le bon endroit.

Cette solution peut être un peu bâclée, mais je pense que c'est le moindre de plusieurs maux. Quoi qu'il en soit, en fait, la version de votre code de procédure stockée est un must à mon avis.

Answer 2

Je suggère la deuxième option que vous avez fournie. Utilisez un paramètre de version. C'est ce que font les services Web pour qu'ils ne cassent pas le code des applications qui ont commencé à utiliser l'API il y a longtemps, mais l'API est mise à jour à un moment donné. Je parie qu'il y a une logique qui est la même entre les deux versions que vous pourriez extraire dans le fond du proc ou quelque chose. Ou créez potentiellement des fonctions pour les éléments communs et appelez ces fonctions dans vos gros blocs IF/SWTICH.

Answer 3

Je profite de l'occasion pour passer de procédures stockées à un ORM ou une autre approche. Les deux solutions proposées nécessiteraient une sorte de changement de code pour décider quelle procédure stockée utiliser. Au lieu de cela, je l'aurais décider d'utiliser les procédures stockées ou l'ORM. Je voudrais également faire des plans pour éliminer la plupart des procédures stockées. J'ai vu beaucoup de mauvais code et de systèmes foirés dans ma carrière, mais rien ne me pousse à espérer qu'un projet puisse être sauvé comme si je voyais GetItemFromLots_2_Temp_2 dans la liste des procédures stockées. Plusieurs méthodes sont bien plus jolies et plus faciles à maintenir que plusieurs procédures stockées.

(Pour ceux qui aiment les procédures stockées Je ne dis pas qu'elles sont mauvaises Je suis sûr qu'il existe des approches intelligentes pour gérer ce genre de choses en utilisant des procédures stockées mais, si une telle approche était utilisée, question n'aurait pas été posée.

Answer 4

Modifier les procédures stockées existantes pour que la nouvelle logique soit exécutée conditionnellement, uniquement lorsque la proc est appelée dans les circonstances où la nouvelle logique devrait être exécutée ... Si le nouveau proc aurait une interface légèrement différente (set des paramètres sProc) alors vous pouvez les rendre optionnels et utiliser la présence ou l'absence du paramètre un commutateur pour contrôler quel chunkl de code est exécuté dans le proc ...

Lorsque l'ancienne logique n'est plus nécessaire, vous pouvez simplement retirer de la sProcs

Answer 5

Je voudrais aller pour l'option deux fichiers pour les deux raisons suivantes:

• La signature, qui est le nombre de paramètres peuvent changer entre les versions
• Chaque procédure stockée serait plus simple, donc moins de chance d'erreurs de tout le code conditionnel

Answer 6

Nous l'habitude d'utiliser des procédures stockées largement à mon entreprise, mais je les ai (la plupart du temps) éloignés d'ORM. Nous les utilisons toujours, et notre version est la même qu'auparavant: chaque fois que nous modifions les procédures stockées qui restent (que seulement quelques personnes ont le droit de faire), nous sauvegardons le SQL, et stockons le fichier .sql dans notre contrôle de version. C'est imparfait et nous perdons beaucoup de l'intégration que nous avons entre le contrôle de la source et nos fichiers de code (car il n'y a pas d'intégration du serveur SQL dans TFS) mais c'est mieux que pas de contrôle de source du tout.

EDIT - et, bien sûr, cela ne fonctionne que si vous n'avez plus besoin d'utiliser l'ancienne version du proc stocké, car il n'existera plus sous une forme exécutable.

Answer 7

Une autre approche intéressante consisterait à stocker tout le code pour vos procédures stockées dans une table de base de données, avec la version pour le code. Ensuite, vous avez un "front end" proc qui gère les requêtes et ensuite, selon la version, va créer dynamiquement un proc et l'exécuter. Il peut ensuite laisser tomber le proc une fois terminé.

Juste une suggestion sur le mur, mais peut-être travailler pour vous.