Table de Nommage: le trait de Soulignement vs Camelcase? les espaces de noms? Singulier vs Pluriel?
J'ai lu une couple de questions/réponses sur StackOverflow en essayant de trouver la "meilleure", ou devrais-je dire doit accepté, pour le nom des tables dans une Base de données.
La plupart des développeurs ont tendance à nommer les tables en fonction de la langue qui exige la base de données (JAVA, .NET, PHP, etc). Cependant, je pense tout simplement que ce n'est pas le bon.
La manière dont j'ai été nommage des tables jusqu'à maintenant est en train de faire quelque chose comme:
doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents
Les choses que je suis concernés sont:
- Lisibilité
- Rapide d'identification du module de la table est de (|médecins|patients)
- Facile à comprendre, pour éviter les confusions.
Je voudrais lire toutes les opinions à l'égard des conventions de nommage.
Merci.
Vous devez vous connecter pour publier un commentaire.
D'être cohérent est beaucoup plus important que ce régime particulier que vous utilisez.
Je l'utilise généralement PascalCase et les entités sont au singulier:
Il imite les conventions de nommage pour les classes de ma demande de maintenir le tout en très soigné, propre, cohérente, et facile à comprendre pour tout le monde.
Casse la nature de SQL prend en charge
Underscores_Scheme. Logiciels modernes, cependant, prend en charge tout type de schéma de nommage. Cependant, parfois, quelques vilains bugs, d'erreurs ou de facteur humain peut conduire àUPPERCASINGEVERYTHINGde sorte que ceux, qui ont choisi les deuxPascal_CaseetUnderscore_Caseschéma de vivre avec toutes leurs nerfs en bonne place.- Je utiliser des caractères de soulignement. J'ai fait un Oracle de projet il y a quelques années, et il semblait que Oracle forcé tous mes noms des objets à majuscule, qui une sorte de souffle tout tubage régime. Je ne suis pas vraiment un Oracle gars, alors peut-être il y avait un moyen de contourner ce que je n'étais pas au courant, mais ça m'a fait utiliser des traits de soulignement et je ne suis jamais allé en arrière.
Un regroupement de plus de ce qui précède:
Ensuite, vous pouvez facilement traduire (même automatiquement) les noms entre les environnements.
Mais j'aimerais ajouter une autre considération: il se peut qu'il existe d'autres facteurs lorsque vous vous déplacez d'une classe dans votre application à une table dans votre base de données: la base de données de l'objet a vues, les triggers, stockées procs, index, contraintes, etc - qui a également besoin de noms. Ainsi, par exemple, vous pouvez trouver vous-même accéder à des tables via des points de vue qui sont généralement juste un simple "select * from foo". Ceux-ci peuvent être identifiés comme le nom de la table avec juste un suffixe "_v' ou vous pouvez les mettre dans un schéma différent. L'objet de cette simple couche d'abstraction, c'est qu'il peut être étendu si nécessaire, afin de permettre des changements dans un environnement afin d'éviter de toucher les autres. Ce ne serait pas briser le dessus de nommage des suggestions à faire, juste un peu plus de choses à prendre en compte.
J'ai tendance à être d'accord avec les gens qui disent que ça dépend des conventions de la langue que vous utilisez (par exemple, PascalCase pour C# et snake_case pour Ruby).
Jamais camelCase, si.
Puisque la question n'est pas spécifique à une plate-forme ou le moteur de base de données, je dois dire que pour une portabilité maximale, vous devez toujours utiliser des minuscules les noms de table.
/[a-z_][a-z0-9_]*/est vraiment le seul motif de noms que de façon transparente se traduit entre les différentes plates-formes. Minuscules alpha-numérique+trait de soulignement sera toujours travailler de manière cohérente.
Comme mentionné ailleurs, rapport (tableau) les noms au singulier: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html
Après avoir lu beaucoup d'autres opinions, je pense qu'il est très important d'utiliser les conventions de nommage de la langue, la cohérence est plus important que les conventions de nommage que si vous êtes (et sera) le seul développeur de l'application. Si vous voulez la lisibilité (qui est d'une importance énorme) il vaut mieux utiliser les conventions de nommage pour chaque langue. Dans MySQL par exemple, je vous suggère de ne pas utiliser CamelCase depuis pas toutes les plates-formes sont sensibles à la casse. Donc ici souligner va mieux.
camelCaseàcamelcase. Donc, avoir de serpent de cas est beaucoup mieux. Également surModern software however supports any kind of naming schemevous n'avez pas toutes les garanties que yop va écrire le code de la dernière version du soft. En particulier pour la base de données - version mise à jour n'est pas anodin quand vous pensez à la régression des coûts.Ce sont mes cinq cents. Je suis venu à la conclusion que si DBs provenant de fournisseurs différents sont utilisés pour un projet, il y a deux moyens les plus efficaces:
La raison en est que certains de la base de données vous permet de convertir tous les caractères en majuscules et en minuscules. Donc, si vous avez
myTableil deviendraMYTABLEoumytablequand vous allez travailler avec DB.Malheureusement, il n'existe pas de "meilleure" réponse à cette question. Comme @David a déclaré la cohérence est de loin plus importante que la convention de nommage.
il y a une grande variabilité sur la façon de séparer les mots, alors là vous aurez à choisir ce que vous aimez mieux; mais, dans le même temps, il semble qu'il est près de consensus que le nom de la table doit être au singulier.
Conventions de nommage existent pas dans le champ d'application de la langue, et des langues différentes ont différentes conventions de nommage.
SQL est insensible à la casse par défaut; ainsi, snake_case est largement utilisé de la convention. SQL prend également en charge les identificateurs délimités; ainsi, des majuscules et des minuscules dans une option, comme camelCase (Java, où les champs de == colonnes) ou PascalCase (C#, où les tables == classes et des colonnes == champs). Si votre moteur de base de données ne peut pas supporter du standard SQL, c'est son problème. Vous pouvez décider de vivre avec ou de choisir un autre moteur. (Et pourquoi C# se devait d'être différent est un point d'aggravation pour ceux d'entre nous qui code en deux.)
Si vous comptez utiliser une seule langue dans vos services et applications, utiliser les conventions de la langue à tous les niveaux. D'autre, utiliser le plus largement utilisé des conventions de la langue dans le domaine où cette langue est utilisée.