Pour exécuter les bases de données SQL Server avec succès, vous devez être passionné par la conception des requêtes. Malheureusement, la plupart des gens ne réfléchissent pas au processus de conception. En conséquence, ils commettent des erreurs simples qui, bien qu'elles soient faciles à éviter, ont des conséquences considérables.
Pour commencer, avec des requêtes mal écrites, vous ne pouvez pas garantir aux utilisateurs des temps de récupération ultra-rapides. Vos serveurs seront également en proie à des problèmes dès le premier jour. Et dans le monde numérique d'aujourd'hui, ce sont des erreurs que vous ne pouvez pas vous permettre de commettre. Mais, comment éviter de faire ces erreurs ? Voici des conseils sur la façon de procéder.
1. Omission d'examiner votre modèle de données
Votre modèle de données détermine la façon dont les utilisateurs accèdent aux données. Alors, réfléchissez à votre modèle dès le début. Si vous ne le faites pas, vous devrez faire face à des requêtes lourdes et à un code compliqué sur toute la ligne, et les deux auront un impact négatif sur les performances. Un moyen simple de déterminer quelles requêtes sont nécessaires pour accéder aux données consiste à imprimer votre modèle de données.
Ou, mieux encore, demandez à un outil de modélisation de données de le faire pour vous. Un outil d'impression ou de modélisation vous permet de voir à quoi vous êtes confronté. Vous êtes donc mieux placé pour simplifier le code, augmenter le temps de codage, augmenter la précision et améliorer les performances.
2. Ne pas tenir compte de votre technique
Quelle technique utilisez-vous ? Est-ce la logique du curseur ou la logique basée sur les ensembles ? Il n'y a pas de réponse facile à cette question particulière :tout dépend de la performance qui correspond le mieux à vos besoins. Prenez la logique basée sur les ensembles, par exemple. C'est le choix évident pour l'accès à la base de données. Après tout, un serveur SQL est conçu pour cela. Mais, la logique du curseur peut dans certains cas surpasser la logique basée. La clé est de ne pas utiliser une technique alors que l'autre serait meilleure.
3. Ne pas utiliser les anciennes techniques de codage
Lorsque vous utilisez des techniques de codage éprouvées, vous rencontrez rarement des problèmes. Même les méthodes de codage que vous avez apprises avec SQL Server 2005 peuvent s'avérer utiles aujourd'hui. Essayez d'utiliser la technique de gestion des erreurs TRY…CATCH dans votre codage. Les résultats pourraient vous surprendre. L'utilisation des expressions de table communes pour les hiérarchies ou du moteur de base de données Common Language Runtime (CLR) peut également vous surprendre.
Si vous avez besoin d'aide pour réviser les anciennes techniques, faites quelques révisions et recherchez des articles en ligne. Il y en a beaucoup là-bas. Voici et voici quelques exemples SQL.
4. Ne pas profiter de l'examen par les pairs
Avant de déployer vos plans de requête, vous devez demander à quelqu'un d'autre de le réviser. Il y a de fortes chances que d'autres personnes voient ce que vous avez manqué. Leurs avis sur vos index et les performances de vos requêtes vous aident souvent à améliorer encore votre code. Ils pourraient également apprendre une chose ou deux de vous au cours du processus, et vice-versa.
5. Échec du test de vos requêtes
Les développeurs détestent avoir à tester du code. D'abord, c'est rigoureux. Et deuxièmement, l'environnement de test (matériel et données) correspond rarement à l'environnement de production réel. Mais les tests sont une partie nécessaire et inévitable du codage. Alors, testez minutieusement votre code et, si possible, essayez d'imiter le plus possible l'environnement de production final. N'oubliez pas que vos requêtes peuvent bien fonctionner avec quelques centaines d'enregistrements, mais pas contre des millions dans l'environnement final.
Conclusion
Les requêtes déterminent la vitesse et les performances d'une base de données SQL. Essayez donc d'éviter les erreurs courantes telles que ne pas revoir votre modèle de données ou ne pas réfléchir à la technique à utiliser. D'autres n'utilisent pas les anciennes techniques de codage, ne profitent pas des mécanismes d'examen par les pairs et ne testent pas vos requêtes.
