Nom du tableau: Underscore vs Camelcase? espaces de noms? Singulier vs pluriel?

89

J'ai lu quelques questions / réponses sur StackOverflow en essayant de trouver le `` meilleur '', ou devrais-je dire le moyen accepté, de nommer des tables sur une base de données.

La plupart des développeurs ont tendance à nommer les tables en fonction du langage qui requiert la base de données (JAVA, .NET, PHP, etc.). Cependant, je pense que ce n'est pas juste.

La façon dont j'ai nommé les tables jusqu'à présent est de faire quelque chose comme:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

Les choses qui me concernent sont:

Lisibilité
Identification rapide du module de la table (médecins || patients)
Facile à comprendre, pour éviter les confusions.

J'aimerais lire les opinions concernant les conventions de dénomination. Merci.

database database-design

— MarioRicalde
source

180

Être cohérent est bien plus important que le schéma particulier que vous utilisez.

— David Oneill
source

21

En d'autres termes, oui, bravo, vous avez identifié des schémas cohérents. Allez-y!

— Phil H

3

+1 pour le commentaire. De plus, en passant par le schéma de dénomination actuel, PascalCase est meilleur, surtout si vous n'utilisez pas d'alias pour les requêtes SQL. De cette façon, vous pouvez simplement utiliser camelcase sur les noms de colonne de table et Pascal Case sur les noms de table.

— MarioRicalde

3

La casse Pascal / camel pour les noms de table peut entraîner des problèmes. Chaque table aura un fichier dans le système de fichiers, et certains d'entre eux sont insensibles à la casse (par exemple OSX).

— ismriv

2

@ismriv ce n'est un problème que si vous êtes incohérent, si vous faites toujours référence à des tables / vues / colonnes avec le même cas cohérent, vous ne devriez pas avoir de problèmes, ne pas être paresseux lors de l'écriture de ces noms vous rapportera un gros avantage plus tard lors de la lecture. L'utilisation de PascalCase pour les tableaux et de camelCase pour les colonnes permet d'identifier le type d'un nom en un coup d'œil et imite également les conventions courantes orientées objet.

— TWiStErRob

Je suis tout à fait d'accord que la cohérence est la clé, mais c'est une vieille question et pour les personnes utilisant des plates-formes de base de données plus récentes comme Redshift et Snowflake qui utilisent par défaut tous les identifiants majuscules ou minuscules, j'ajouterais qu'il est très important de penser à votre les conventions de dénomination dès le début. Choisir d'utiliser une convention de dénomination comme Camel Case sur ces plates-formes peut vous causer des maux de tête inutiles plus tard, par exemple, vous devrez utiliser des identifiants entre guillemets tout le temps et la résolution du nom d'objet peut produire des résultats inattendus.

— Nathan Griffiths

22

J'utilise généralement PascalCase et les entités sont singulières:

DoctorMain
DoctorProfile
DoctorPatient

Il imite les conventions de dénomination des classes de mon application en gardant tout assez net, propre, cohérent et facile à comprendre pour tout le monde.

— Justin Niessner
source

3

Oui ... oui je fais. Je suis un peu brumeux ce matin. Faire le montage ... merci.

— Justin Niessner

3

Il est également connu sous le nom de "CapitalCase".

— corsiKa

3

Je n'ai jamais entendu parler de "CapitalCase" au cours de mes 30 années d'expérience. Je l'ai entendu parler le plus souvent de «cas de chameau» et de «cas de Pascal» plus récemment. Je suis venu ici pour voir pourquoi les gens semblent utiliser la casse camel pour SQL alors qu'elle était historiquement insensible à la casse. Je ne veux certainement pas prendre du retard.

— Sinthia V du

@SinthiaV Je ne sais pas pour les autres mais dans notre cas, puisque nous utilisons un ORM JS (malheureusement), les options étaient 1) break convention en utilisant camelCase dans le db 2) break convention en utilisant snake_case dans JS 3) map camelCase dans JS vers snake_case dans db. Nous avons décidé sans trop de réflexion initiale d'utiliser camelCase dans la base de données, et cela n'a pas été trop mal, mais tout citer est un peu compliqué.

— Andy

@SinthiaV comme un commentaire inutile, cela pourrait être dans le contexte de la question SO réelle, PascalCase n'est pas la même chose que camelCase. PascalCase met en majuscule la première lettre de chaque mot (y compris la première) alors que camelCase ne met en majuscule que les mots après le premier. Lectures

— curieux

11

Nature insensible à la casse des supports SQL Underscores_Scheme. Les logiciels modernes prennent cependant en charge tout type de schéma de dénomination. Cependant, parfois, certains bugs, erreurs ou facteurs humains peuvent conduire à UPPERCASINGEVERYTHINGce que ceux qui ont choisi les deux Pascal_Caseet le Underscore_Caseplan vivent avec tous leurs nerfs en bonne place.

— terR0Q
source

10

Une agrégation de la plupart des éléments ci-dessus:

ne vous fiez pas au cas dans la base de données
ne considérez pas la casse ou le séparateur comme une partie du nom - juste les mots
utilisez le séparateur ou la casse qui est la norme pour votre langue

Ensuite, vous pouvez facilement traduire (même automatiquement) les noms entre les environnements.

Mais j'ajouterais une autre considération: vous constaterez peut-être qu'il existe d'autres facteurs lorsque vous passez d'une classe de votre application à une table de votre base de données: l'objet de base de données a des vues, des déclencheurs, des processus stockés, des index, des contraintes, etc. ont également besoin de noms. Ainsi, par exemple, vous pouvez vous retrouver à n'accéder qu'aux tables via des vues qui ne sont généralement qu'un simple "select * from foo". Ceux-ci peuvent être identifiés comme le nom de la table avec juste le suffixe «_v» ou vous pouvez les mettre dans un schéma différent. Le but d'une couche d'abstraction aussi simple est qu'elle peut être étendue si nécessaire pour permettre des changements dans un environnement afin d'éviter d'avoir un impact sur l'autre. Cela ne casserait pas les suggestions de nommage ci-dessus - juste quelques autres choses à prendre en compte.

— KenFar
source

8

J'utilise des traits de soulignement. J'ai fait un projet Oracle il y a quelques années, et il semblait qu'Oracle forçait tous mes noms d'objet en majuscules, ce qui détruisait tout schéma de casse. Je ne suis pas vraiment un gars d'Oracle, alors peut-être qu'il y avait un moyen de contourner cela dont je n'étais pas au courant, mais cela m'a fait utiliser des traits de soulignement et je n'y suis jamais retourné.

— Rayon
source

2

Dans 11g et plus, la casse semble être conservée si le nom de la table est entouré de guillemets doubles. Mettre ceci ici pour référence future. Je sais avec certitude que Postgres le fait aussi, pas d'autres moteurs db.

— John O

8

Étant donné que la question n'est pas spécifique à une plate-forme ou à un moteur de base de données particulier, je dois dire que pour une portabilité maximale, vous devez toujours utiliser des noms de table en minuscules.

/ [a-z _] [a-z0-9 _] * / est vraiment le seul modèle de noms qui se traduit de manière transparente entre différentes plates-formes. Les minuscules alphanumériques + soulignement fonctionneront toujours de manière cohérente.

Comme mentionné ailleurs, les noms de relation (table) doivent être au singulier: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

— riche souvenir
source

Je suis d'accord - le soulignement a le moins de problèmes à comparer avec Pascal ou camel Casing. Surtout lorsque vos noms voyagent vers des modèles, dto et frontend à la fin.

— Saulius

6

J'ai tendance à être d'accord avec les gens qui disent que cela dépend des conventions de langage que vous utilisez (par exemple PascalCase pour C # et snake_case pour Ruby).

Jamais camelCase, cependant.

— Mark Rendle
source

2

Ada: Pascal_Case_With_Underscores

— uetoyo

6

Cela n'a pas de sens lorsque vous souhaitez accéder à la même table par deux langues différentes qui ont des conventions de dénomination différentes.

— Daniel W.

5

Après avoir lu beaucoup d'autres opinions, je pense qu'il est très important d'utiliser les conventions de dénomination du langage, la cohérence est plus importante que les conventions de dénomination uniquement si vous êtes (et serez) le seul développeur de l'application. Si vous voulez une lisibilité (ce qui est d'une importance capitale), il vaut mieux utiliser les conventions de dénomination pour chaque langue. Dans MySQL par exemple, je ne suggère pas d'utiliser CamelCase car toutes les plates-formes ne sont pas sensibles à la casse. Donc, ici, le soulignement va mieux.

— Vlad Manuel Mureșan
source

1

Tout à fait d'accord!!! Surtout avec MySql lorsque vous l'exécutez sous Windows, tout devient de camelCaseà camelcase. Donc, avoir un cas de serpent est bien mieux. De plus, Modern software however supports any kind of naming schemevous n'avez aucune garantie que vous écrirez du code pour la dernière version du logiciel. Surtout pour la base de données - la mise à jour de la version n'est pas anodine quand on pense aux coûts de régression.

— Cherry

2

Ce sont mes cinq cents. Je suis arrivé à la conclusion que si des bases de données de différents fournisseurs sont utilisées pour un projet, il existe deux meilleures façons:

Utilisez des traits de soulignement.
Utilisez le cas de chameau avec des citations.

La raison en est que certaines bases de données convertissent tous les caractères en majuscules et certains en minuscules. Donc, si vous l'avez, myTableil deviendra MYTABLEou mytablequand vous travaillerez avec DB.

— Pavel_K
source

1

Malheureusement, il n'y a pas de «meilleure» réponse à cette question. Comme @David l'a déclaré, la cohérence est bien plus importante que la convention de dénomination.

— Kane
source

1

il y a une grande variabilité sur la façon de séparer les mots, vous devrez donc choisir ce que vous préférez; mais en même temps, il semble qu'il y ait presque un consensus sur le fait que le nom de la table doit être au singulier.

— Javier
source

1

Les conventions de dénomination existent dans le cadre d'une langue, et différentes langues ont des conventions de dénomination différentes.

SQL est insensible à la casse par défaut; ainsi, snake_case est une convention largement utilisée. SQL prend également en charge les identificateurs délimités; donc, casse mixte dans une option, comme camelCase (Java, où champs == colonnes) ou PascalCase (C #, où tables == classes et colonnes == champs). Si votre moteur de base de données ne prend pas en charge la norme SQL, c'est son problème. Vous pouvez décider de vivre avec cela ou choisir un autre moteur. (Et pourquoi C # devait juste être différent est un point d'aggravation pour ceux d'entre nous qui codent dans les deux.)

Si vous avez l'intention de n'utiliser qu'une seule langue dans vos services et applications, utilisez les conventions de cette langue à toutes les couches. Sinon, utilisez les conventions les plus largement utilisées de la langue dans le domaine où cette langue est utilisée.

— Chris Golledge
source