Neuf bonnes pratiques T-SQL

Choisissez le type de données approprié

Quand vous créez un tableau, vous devez décider du type de données à utiliser dans les définitions des colonnes. Un type de données définit la sorte des données stockables dans une colonne. Les types de données servent aussi à définir des variables et des paramètres d’entrée et de sortie des procédures stockées.

Pour chaque colonne ou variable, vous devez sélectionner un type de données approprié aux données enregistrées dans cette colonne ou variable. De plus, vous devez prendre en compte les impératifs de stockage et choisir des types de données qui permettent un stockage efficace. Par exemple, utilisez toujours tinyint au lieu de smallint, int ou bigint pour stocker des entiers positifs entre 0 et 255. En effet, ces derniers sont des champs à longueur fixe : 1 octet pour tinyint, 2 octets pour smallint, 4 octets pour int et 8 octets pour bigint.

Le choix des types de données appropriés améliore également l’intégrité des données. Par exemple, si vous définissez un type de données DateHeure pour une colonne de dates, seules des dates pourront ensuite y être stockées. En revanche, si vous choisissez un type de données Caractère ou Numérique pour cette colonne, on pourra alors y stocker n’importe quelle valeur de données de type Caractère ou Numérique sans que cette valeur ne représente une date.

Enfin, le choix du type de données correct améliore les performances, car il entraîne la création du plan d’exécution correct.

Évitez les clauses DISTINCT ou UNION

La clause DISTINCT dans les requêtes T-SQL supprime les doublons des résultats. Si vous êtes sûr que le jeu de résultats de votre requête contient exclusivement des lignes uniques, un des bonnes pratiques de T-SQL consiste à éviter la clause DISTINCT qui entraîne une opération de classement inutile.

La clause UNION ajoute aussi une opération de classement supplémentaire en ce qu’elle supprime les doublons à l’aide de plusieurs instructions SELECT. Pour combiner les résultats de plusieurs instructions SELECT qui contiennent uniquement un seul jeu de données, mieux vaut utiliser la clause UNION ALL au lieu de la clause UNION. La clause UNION ALL ne supprime pas les doublons : elle consomme moins de ressources de traitement du serveur SQL en backend pour réaliser l’opération d’union.

Évitez d’utiliser l’indicateur de requête NOLOCK

L’indicateur de requête NOLOCK est une des bonnes pratiques T-SQL les plus courantes mais peut aussi s’avérer une des pires. La plupart des développeurs pensent que le risque inhérent à un indicateur NOLOCK est l’incohérence des données, puisque la lecture se fait par ligne, sans attendre la validation des autres lignes (par d’autres instructions SQL, SELECT et UPDATE par exemple). C’est vrai, mais NOLOCK va au-delà de la lecture de lignes non validées. Les transactions font plus que la simple sélection, mise à jour et suppression de lignes. Par exemple, la transaction requiert souvent la mise à jour d’un indice ou ne dispose plus d’espace suffisant dans la page des données. Il faut alors attribuer de nouvelles pages et réadresser des lignes de la page existante dans cette nouvelle page. Cette opération est dite de « fractionnement de page ». Vous risquez de louper plusieurs lignes ou d’obtenir deux fois les mêmes, ce qui est généralement interdit dans les requêtes sans l’indicateur NOLOCK.

Précisez les listes complètes des colonnes pour les instructions SELECT ou INSERT

Une autre bonne pratique T-SQL est de toujours préciser les listes complètes des colonnes requises pour les instructions SELECT et INSERT. Par exemple, si vous utilisez SELECT * FROM dans votre code ou dans une procédure stockée, la liste des colonnes est résolue chaque fois que vous exécutez l’instruction SELECT. De plus, les instructions SELECT ou INSERT créent une erreur ou renvoient un autre jeu de colonnes en cas de modification du schéma des tables sous-jacentes.

Ainsi, lors de l’exécution de l’instruction de sélection, évitez d’utiliser SELECT * FROM [NomDeTable] et précisez plutôt la liste complète des colonnes comme suit :

SELECT [col1],…[coln] FROM [NomDeTable]

De la même façon, pour les instructions d’insertion, utilisez la liste des colonnes dans la clause INSERT :

INSERT INTO [NomDeTable] [col1],[col2]…[coln])

VALUES (‘Valeur1, Valeur2,…ValeurN)

Cinq bonnes pratiques T-SQL supplémentaires

Utilisez SET NOCOUNT ON. SET NOCOUNT ON dans les lots, les procédures stockées et les déclencheurs pour accélérer les performances. En effet, lorsqu’on utilise cette instruction, le résultat de la requête n’indique pas le nombre de lignes concernées.

Préférez EXISTS à IN. Pour vérifier l’existence d’enregistrements, favorisez le mot clé EXISTS au lieu de IN, car ce dernier traite des listes et renvoie le jeu de résultats complet des sous-requêtes avant de poursuivre avec les autres traitements. Les sous-requêtes à base du mot clé EXISTS retournent un résultat VRAI ou FAUX, ce qui est plus rapide puisque, une fois qu’un résultat est trouvé, elles s’arrêtent, car la condition est vérifiée.

Évitez les curseurs. Évitez autant que possible les curseurs. À la place, suivez une approche basée sur les jeux pour mettre à jour les données ou en insérer d’une table à l’autre.

Restez à distance du SQL dynamique. Évitez d’utiliser le SQL dynamique ; cherchez d’autres solutions qui ne font pas appel à SQL dynamique. Si vous devez l’utiliser, utilisez sp_executesql au lieu de EXECUTE (EXEC), car sp_executesql est plus efficace et polyvalent. SQL dynamique prend en charge la substitution de paramètres et crée des plans d’exécution plus susceptibles d’être réutilisés par SQL Server.

Utilisez des noms d’objets qualifiés par un schéma. Référez-vous aux noms des tables avec des préfixes de noms de schémas. Par exemple, utilisez SELECT * FROM [NomDuSchema].[NomDeTableau] au lieu de SELECT * FROM [NomDeTableau].