Dans le monde des bases de données, certaines choses sont universellement acceptées. L'augmentation de la RAM est largement bénéfique pour les systèmes DMBS. La répartition des données et des fichiers journaux sur RAID améliore les performances.
Les conventions de nommage n'en font pas partie.
Il s'agit d'un sujet étonnamment polarisant, les partisans de diverses méthodologies étant fermement ancrés dans leurs positions. Et très vocal et passionné dans leur défense de la même chose.
Cet article approfondira certaines des conventions spécifiques et des arguments des deux côtés, tout en essayant de présenter une conclusion raisonnable pour chaque point.
Le grand débat sur la pluralité
À la base, il s'agit d'un sujet simple. Par exemple, comment nommer correctement une table contenant des informations client dans un schéma de base de données relationnelle ? Est-ce Customer ou Customers ?
Les arguments des deux côtés abondent.
À première vue , il est naturel de penser à une collection d'objets au pluriel. Un groupe de plusieurs individus ou entreprises serait Clients . Par conséquent, une table (étant une collection d'objets) doit être nommée au pluriel. Une ligne individuelle dans ce tableau serait un seul client .
Les principes de dénomination ISO/CEI, bien que datés, recommandent des noms de table au pluriel et des noms de colonne au singulier.
La plupart des tables système SQL Server utilisent des noms au pluriel (sysnotifications , opérateurs système ), mais c'est incohérent. Pourquoi sysproxylogin et non sysproxylogins ?
Dans les arguments pour les noms de table au pluriel, les lignes d'une table sont également référencées comme des « instances » d'un tout, comme les éléments d'une collection. Clients définit l'ensemble; un seul client est une instance de Clients .
À l'inverse, il existe de nombreuses raisons d'utiliser des noms d'objets singuliers.
Bien qu'il puisse y avoir de nombreux articles (ou clients ) dans une table, la table elle-même peut être considérée comme une seule entité. une boîte de clients n'est pas "une boîte de clients", même si elle contient un grand nombre de clients. De plus, il peut n'y avoir qu'un seul élément - ou aucun - à l'intérieur du tableau, ce qui rend le terme "clients" impropre.
Si vous choisissez de modifier le nom du tableau en fonction des variantes de mots, des incohérences peuvent rapidement apparaître. Bien que de nombreux mots soient simples (Client devient Clients , Produit devient Produits ), d'autres mots peuvent ne pas l'être. Dans ce cas, Personne pourrait devenir Personnes ou Personnes; un orignal singulier ressemblerait à sa forme plurielle, Moose . (Mais pourquoi auriez-vous besoin d'une table d'orignaux ?) Une convention telle que People.FirstName commence à devenir confus et confus.
Si plusieurs langues sont impliquées, la situation s'aggrave encore. Parce que la pluralisation des mots peut varier de tant de manières (clients, souris, orignal, enfants, crises, syllabus, avions), les locuteurs non natifs ont des défis supplémentaires. S'en tenir à des noms d'objets singuliers évite complètement ce problème.
La question de la convention de cas
Il n'y a pas la même ferveur avec les conventions de casse qu'avec la pluralisation, mais des arguments sont avancés pour plusieurs options différentes. Ils incluent :
- Cas Pascal :La première lettre de chaque mot concaténé est en majuscule, comme dans :
CustomerOrder -
Étui Chameau :La première lettre du premier mot est en minuscule; tous les mots concaténés suivants ont une première lettre en majuscule, comme dans :
customerOrderPascal Case est parfois considéré comme un sous-type de Camel Case, mais Microsoft fait généralement la différence entre les deux.
Pour les mots de moins de trois caractères, il est recommandé de n'utiliser que des majuscules, comme dans
UIouIO. - Traits de soulignement [cas "C"] :les mots sont séparés par des traits de soulignement, comme dans
Customer_Order, oucustomer_Order– encore plus de décisions !
Des chercheurs de l'Université Johns Hopkins ont mené une étude sur l'efficacité de l'utilisation des traits de soulignement dans la programmation des noms d'objets. Ils ont constaté que l'utilisation de Camel Case (ou Pascal Case) améliorait la précision et la reconnaissance de la frappe. Les traits de soulignement étaient largement utilisés dans la programmation C, mais la tendance est au cas Camel/Pascal avec un accent récent sur les langages de style Microsoft et Java.
Comme pour les autres sujets, suivant une convention établie est plus importante que la sélection de la convention elle-même.
Une considération supplémentaire ici est la sensibilité à la casse de la base de données. Le classement SQL Server détermine cette sensibilité avec « CS » (sensible à la casse) ou « CI » (insensible à la casse) dans le nom du classement. Par exemple :
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
Dans les classements sensibles à la casse, Select * from myTable échouerait contre l'objet MyTable . Cela peut rendre les traits de soulignement légèrement préférables pour éviter toute confusion, mais Intellisense aide également à éliminer les erreurs de frappe dans la plupart des environnements de programmation modernes.
Autres considérations relatives aux conventions de dénomination
Le débat entre singulier et pluriel et la grande question de cas sont peut-être ceux où la bataille est la plus féroce, mais il y a au moins trois autres domaines à garder à l'esprit lors de l'examen d'une convention de dénomination.
Évitez d'utiliser des mots réservés SQL Server comme noms d'objets. Cela inclut à la fois les tables et les colonnes. Par exemple – Utilisateur , Heure , et date sont réservés. Les mots-clés réservés peuvent nécessiter une référence supplémentaire (comme l'utilisation de crochets) en fonction de l'application appelante. Cela s'applique également aux espaces. Les espaces dans les noms d'objet nécessitent des guillemets pour référence.
Cela rejoint également une autre recommandation - la précision. System.CreateDate est beaucoup plus clair que System.Date . Un modèle bien conçu permet au spectateur de comprendre immédiatement le but des objets sous-jacents. Lorsque des identifiants doivent être référencés en tant que clés étrangères, soyez libéral dans le nom - Customer.CustomerID plutôt que Customer.ID .
Évitez les préfixes et les suffixes pour les tables et les vues , comme tblTable . La notation hongroise (qui a toujours été destinée à identifier l'utilisation des variables) s'est glissée dans les conventions de dénomination courantes de SQL Server, mais elle est largement ridiculisée. Les identificateurs d'objet doivent décrire ce qu'ils contiennent, et non l'objet lui-même.
Cependant, les préfixes sont utiles dans les objets prenant en charge SQL Server , car ils décrivent la nature fonctionnelle de l'objet.
Les préfixes suivants sont généralement acceptés pour les objets SQL Server :
- IX :Index
- PK :clé primaire
- FK :clé étrangère
- CK :Vérifier la contrainte
- DF :par défaut
- UQ est parfois également utilisé pour les index uniques.
Ce modèle illustre les points définis ci-dessus. Il ne nécessite aucune explication quant à la nature des données; des conventions de dénomination au singulier sont utilisées et des identifiants clairs sont en place.
En fin de compte, il y a des avantages et des inconvénients de chaque côté du débat sur la dénomination de la convention. Il y a cependant un point clé sur lequel les deux parties peuvent s'entendre :quelles que soient les décisions prises, soyez cohérent avec la convention choisie.
Quelles conventions de dénomination SQL utilisez-vous et pourquoi ?
