Quelqu'un peut-il recommander des normes de codage pour TSQL?


9

Nous avons depuis longtemps des normes de codage pour notre code .Net, et il semble y avoir plusieurs sources réputées pour des idées sur la façon de les appliquer qui évoluent avec le temps.

Je voudrais pouvoir rassembler quelques normes pour le SQL qui est écrit pour être utilisé par nos produits, mais il ne semble pas y avoir de ressources sur le consensus pour ce qui détermine un SQL bien écrit?


1
Pinal Dave a une liste de normes de codage sur son site . Ils ressemblent à une base équitable pour un ensemble de normes.
Will A


1
@Scott qui ne couvre que l'identification; rien sur la dénomination, l'utilisation de curseurs / procédures stockées / choix de type de données ou tout ce qui affecte réellement la qualité du code ...
Rowland Shaw

1
exactement, d'où la raison pour laquelle j'ai dit que c'était "lié", pas un "doublon".
Scott Whitlock

Réponses:


6

D'après mon expérience, les principales choses que je rechercherais seraient:

  • Dénomination des tables et des colonnes - vérifiez si vous utilisez ID, Reference ou Number pour les colonnes de type ID, singulier ou pluriel pour les noms (les pluriels sont communs pour les noms de table - par exemple THINGS, singulier pour les noms de colonne - par exemple THING_ID). Pour moi, les choses les plus importantes ici sont la cohérence qui évite aux gens de perdre du temps (par exemple, vous ne rencontrez pas de fautes de frappe où quelqu'un a mis THING comme nom de table parce que vous savez intuitivement que les noms de table ne sont jamais singuliers).

  • Toutes les créations doivent inclure une goutte (conditionnelle à l'objet existant) dans leur fichier. Vous pouvez également vouloir inclure des autorisations de subvention, à vous de choisir.

  • Les sélections, les mises à jour, les insertions et les suppressions doivent être disposées avec un nom de colonne, un nom de table et un clause clause / order by par ligne afin de pouvoir être facilement commentés un par un pendant le débogage.

  • Préfixe pour les types d'objets, en particulier là où ils peuvent être confondus (donc v pour view étant le plus important). Je ne sais pas si cela s'applique toujours, mais il était auparavant inefficace pour les procédures stockées autres que les procédures système de commencer sp_. La meilleure pratique pour les différencier de toute façon est probablement usp_ que j'ai utilisé le plus récemment.

  • Une norme indiquant comment le nom d'un déclencheur doit inclure s'il s'agit de mise à jour / insertion / suppression et le tableau auquel il s'applique. Je n'ai pas de norme préférée, mais ce sont des informations essentielles et doivent être faciles à trouver.

  • Standard pour la propriété des objets dans les versions antérieures de SQL Server ou le schéma dans lequel il doit exister pour 2005 et versions ultérieures. C'est votre appel ce que c'est mais vous ne devez jamais deviner à qui appartient quelque chose / où il vit) et, si possible, le schéma / propriétaire doit être inclus dans les scripts CREATE pour minimiser la possibilité qu'il soit créé à tort.

  • Un indicateur que toute personne utilisant SELECT * sera amenée à boire une pinte de sa propre urine.

  • À moins qu'il n'y ait une très, très bonne raison (qui n'inclut pas la paresse de votre part), ayez, appliquez et maintenez des relations clé primaire / clé étrangère dès le départ. C'est après tout une base de données relationnelle et non un fichier plat et les enregistrements orphelins vont faire de votre vie de support un enfer à un moment donné. Sachez également que si vous ne le faites pas maintenant, je peux vous promettre que vous n'arriverez jamais à l'implémenter après l'événement, car c'est 10 fois le travail une fois que vous avez des données (ce qui sera un peu foutu parce que vous n'avez jamais appliqué les relations correctement).

Je suis sûr que j'ai raté quelque chose, mais pour moi, ce sont ceux qui offrent réellement de réels avantages dans un nombre décent de situations.

Mais comme pour toutes les normes, moins c'est plus. Plus vos normes de codage sont longues, moins les gens sont susceptibles de les lire et de les utiliser. Une fois que vous avez dépassé quelques pages bien espacées, commencez à chercher à supprimer ce qui ne fait pas vraiment de différence pratique dans le monde réel, car vous réduisez simplement les chances que les gens le fassent.

EDIT: deux corrections - y compris les schémas dans la section de propriété, supprimant une astuce erronée sur le nombre (*) - voir les commentaires ci-dessous.


1
Quelques choix étranges ... "SELECT COUNT (*)" est mauvais? Avez-vous déjà entendu parler de schémas (ce qui n'est pas la même chose que le propriétaire)? Vos autres sont bons cependant
gbn

1
@Jon Hopkins - Je sais pourquoi il est mauvais d'utiliser SELECT *. Ce serait formidable si vous pouviez dire pourquoi l'utilisation de SELECT COUNT (*) est mauvaise.
k25

1
@gbn @ k25 - Il y a quelques années (2002?), j'avais un DBA qui était très chaud sur le compte (*) mais googler en réponse à vos questions, il semble que ce soit désormais dépassé (si cela était jamais vrai). sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (Inscription requise). Elle était principalement un DBA Oracle, donc cela peut avoir été un véritable problème là-bas qui, selon elle, était également un problème pour l'optimiseur SQL.
Jon Hopkins

1
@gbn - Oui, bien que je sois relativement sans contact depuis leur introduction, ma réaction automatique a donc été les utilisateurs. Je mettrai à jour la réponse pour couvrir les schémas.
Jon Hopkins

1
@gbn, @ k25 - Plus de fouilles sur le nombre (*). Apparemment, c'était un problème dans Oracle 7 et versions antérieures, corrigé dans 8i et au-delà. On ne sait pas si cela a déjà été un problème dans SQL Server, mais ce n'est certainement plus le cas. Mon DBA était obsolète, semble-t-il.
Jon Hopkins

3

il ne semble pas y avoir de ressources sur le consensus pour ce qui détermine un SQL bien écrit

C'est parce qu'il n'y a pas de consensus. À titre d'exemple, j'aurais des réponses différentes pour au moins la moitié des éléments de la liste de Jon Hopkins, et en fonction de la quantité de détails sur sa liste, il est sûr que nous travaillons tous les deux avec des bases de données pour vivre.

Cela dit, une norme de codage est toujours une bonne chose à avoir, et une norme que tout le monde dans l'équipe comprend et approuve est une meilleure chose, car cette norme sera plus probablement suivie.


1
+1. Je pense que la chose la plus importante est que vous avez de la cohérence au sein de votre équipe.
Dean Harding

1
par intérêt que feriez-vous différemment? S'agit-il en grande partie de goût (mise en page, etc.) ou y a-t-il des erreurs "dures"?
Jon Hopkins

1
@ Jon: pas d'erreurs matérielles, juste des choses subjectives comme des noms de table singuliers, la haine des déclencheurs, etc. BTW, "SELECT *" est bien dans un "EXISTS ()".
Larry Coleman,

1
juste exemple (et je l'utilise avec EXISTS et ne me force pas à boire de l'urine).
Jon Hopkins

1

En plus de la réponse de Jon Hopkins ...

  • Objets internes et externes séparés

    • IX, UQ, TRG, CK, etc. pour les contraintes et les index, etc.
    • minuscules ou CapsCase pour le client, par exemple uspThing_Add
  • Pour les objets internes, rendez-les explicites si "non par défaut"

    • UQ = contrainte unique
    • UQC = contrainte cluster unique
    • PK = clé primaire
    • PKN = clé primaire non clusterisée
    • IX = indice
    • IXU = index unique
    • IXC = index clusterisé
    • IXCU ou IXUC = index cluster unique
  • Utilisez des schémas pour simplifier le nommage + les autorisations. Exemples:

    • Helper.xxx pour les procs internes
    • HelperFn.xxx pour udfs
    • WebGUI.xxx pour certains codes en regard
    • Données et / ou historique et / ou mise en scène pour les tableaux
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.