Comment maintenez-vous de grandes procédures t-sql

Question

Je suis sur le point d'hériter d'un ensemble de procédures stockées volumineuses et complexes qui effectuent un traitement mensuel sur de très grands ensembles de données.

Nous sommes en train de les déboguer afin qu’ils correspondent au processus original écrit en VB6. La raison pour laquelle ils ont décidé de les réécrire dans t-sql est parce que le processus vb prend des jours et que le nouveau processus prend des heures.

Tout cela va bien, mais comment puis-je rendre ces morceaux maintenant énormes de code t-sql (1,5k + lignes) même lisibles à distance / maintenables.

Toute expérience faisant de t-sql peu de maux de tête est la bienvenue.

Answer 1

Créez d’abord un répertoire de fichiers .sql et conservez-les. Ajoutez cet ensemble de fichiers .sql à un système de contrôle de révision. SVN fonctionne bien. Ayez un outil qui les charge dans votre base de données, en écrasant celles qui existent.

Disposez d'une base de données de tests et de rapports de base indiquant à quoi devrait ressembler le résultat du traitement mensuel. Vos tests doivent également être sous la forme de fichiers .sql sous contrôle de version.

Vous pouvez maintenant modifier vos processus autant de fois que vous le souhaitez, puis exécuter vos tests pour confirmer le bon fonctionnement.

Answer 2

Pour le formatage / la mise en forme de SQL, j'ai eu du succès avec http: //www.sqlinform .com / : une version gratuite en ligne que vous pouvez essayer et une version pour ordinateur de bureau également disponible.

  

SQLinForm est un formateur de code SQL automatique pour toutes les bases de données principales (ORACLE, SQL Server, DB2 / UDB, Sybase, Informix, PostgreSQL, MySQL, etc.) avec de nombreuses options de formatage.

Answer 3

Commencez par reformater le code, en particulier les indentations.

Modulez ensuite le code SQL. Extrayez des morceaux en procédures et fonctions plus petites et nommées de manière descriptive dans leurs propres fichiers autonomes. Je trouve que cela seul fonctionne très bien pour améliorer ma compréhension des fichiers SQL volumineux.

Answer 4

ApexSQLScript est un excellent outil pour scripter une base de données entière. Vous pouvez ensuite le vérifier dans le contrôle de source et gérer les modifications.

J'ai également constaté que la documentation des sprocs vous permettait d'extraire des informations à leur sujet en utilisant les données relatives au code source dans sys.sql_modules. Vous pouvez utiliser des balises ou autre chose pour aider à la documentation des sous-systèmes.

Utilisez également des schémas (ou même plusieurs bases de données). Cela vous aidera vraiment à diviser votre base de données en unités logiques et à signaler les problèmes d'architecture.

En ce qui concerne le gros code, j'ai récemment constaté que la fonctionnalité SQL2005 CTE était très utile pour la gestion de code comportant de nombreuses requêtes imbriquées (même pas récursives). Au lieu de gérer un ensemble d'imbrication et d'indentation, les CTE peuvent être déclarés et construits, puis utilisés dans la déclaration finale. Cela facilite également le refactoring car il semble beaucoup plus facile de supprimer les requêtes et les colonnes imbriquées redondantes.

Les procédures stockées et les fichiers UDF sont essentiels pour gérer une base de code volumineuse et éliminer les coins sombres. Je n’ai pas trouvé les vues très utiles car elles ne sont pas paramétrables (les fichiers UDF peuvent être utilisés dans ces cas-là si les ensembles de résultats sont petits).

Answer 5

Essayez de modulariser autant que possible le code SQL et d’avoir un ensemble de tests qui vous permettront de maintenir, de refactoriser et d’ajouter des fonctionnalités au besoin. Une fois, j'ai eu le plaisir d'hériter d'un processus stocké qui totalisait 5000 lignes et j'ai toujours des cauchemars à ce sujet. Une fois le projet terminé, j’ai imprimé le processus stocké pour un rire qui désordonne X arbres. Au cours d'une de nos réunions hebdomadaires de stand-up, j'ai tout mis en œuvre pour étendre le bâtiment. C’est un exemple de la façon dont il est interdit d’écrire et de maintenir des procédures stockées.

Answer 6

Une chose que vous pouvez faire est de disposer d'un script automatisé pour stocker toutes les modifications apportées au contrôle de source afin de pouvoir examiner les modifications apportées aux procédures (à l'aide d'un diff sur les versions précédente et actuelle)

Answer 7

Ce n’est certainement pas gratuit, mais pour garder votre T-SQL formaté de manière cohérente, le Invite SQL est très pratique. Tant que la syntaxe de votre proc est correcte, quelques frappes de touche (Ctrl + K, Y) la reformateront instantanément. Les options vous permettent de contrôler beaucoup le formatage de votre code SQL.