Tableau Dilemme de dénomination: noms singuliers vs noms pluriels
Les universités ont déclaré que les noms de table devraient être le singulier de l'entité dont ils stockent les attributs.
Je n'aime pas les T-SQL qui nécessitent des crochets autour des noms, mais j'ai renommé une table Users en singulier, condamnant à tout jamais les personnes utilisant la table à parfois utiliser des crochets.
Mon instinct est qu'il est plus correct de rester avec le singulier, mais mon intuition est aussi que les crochets indiquent des indésirables comme des noms de colonnes avec des espaces, etc.
Dois-je rester ou dois-je partir?
D'autres ont donné d'assez bonnes réponses en ce qui concerne les "normes", mais je voulais juste ajouter ceci ... Est-il possible que "Utilisateur" (ou "Utilisateurs") ne soit pas réellement une description complète des données contenues dans le tableau ? Ce n'est pas que vous deveniez trop fou avec les noms de tables et leur spécificité, mais peut-être quelque chose comme "Widget_Users" (où "Widget" est le nom de votre application ou de votre site Web) serait plus approprié.
J'avais la même question et après avoir lu toutes les réponses, je reste définitivement avec SINGULAR, pour les raisons suivantes:
Raison 1 (Concept). Vous pouvez penser à un sac contenant des pommes comme "AppleBag". Peu importe qu’il contienne 0, 1 ou un million de pommes, c’est toujours le même sac. Les tables ne sont que des conteneurs, le nom de la table doit décrire ce qu’elle contient, pas la quantité de données qu’elle contient. En outre, le concept pluriel concerne davantage une langue parlée (en fait, pour déterminer s’il en existe une ou plusieurs).
Raison 2. (Commodité). il est plus facile de sortir avec des noms singuliers que avec des noms pluriels. Les objets peuvent avoir des pluriels irréguliers ou pas du tout, mais en auront toujours un singulier (à quelques exceptions près, comme News).
- Client
- Ordre
- Utilisateur
- Statut
- Nouvelles
Raison. (Esthétique et Ordre). Spécialement dans les scénarios maître-détail, cela lit mieux, aligne mieux par nom et a plus d'ordre logique (Maître en premier, Détail en second):
- 1.Order
- 2. OrdreDétail
Par rapport à:
- 1.OrdreDétails
- 2.Ordres
Raison 4 (Simplicité). Tous ces éléments réunis (noms de table, clés primaires, relations, classes d'entités) ... sont mieux de ne connaître qu'un seul nom (singulier) au lieu de deux (classe singulière, table plurielle, champ singulier, singulier-pluriel maître-détail .. .)
CustomerCustomer.CustomerIDCustomerAddresspublic Class Customer {...}SELECT FROM Customer WHERE CustomerID = 100
Une fois que vous savez que vous avez affaire à "Client", vous pouvez être sûr d’utiliser le même Word pour tous vos besoins en matière d’interaction de base de données.
Raison 5. (Mondialisation). Le monde devient de plus en plus petit, vous pouvez avoir une équipe de nationalités différentes, mais tout le monde n'a pas l'anglais comme langue maternelle. Il serait plus facile pour un programmeur anglophone non natif de penser à "Référentiel" plutôt qu'à "Référentiels" ou à "Statuts" au lieu de "Statut". Avoir des noms singuliers peut réduire le nombre d'erreurs causées par les fautes de frappe, gagner du temps en évitant de penser "est-ce un enfant ou des enfants?", Améliorant ainsi la productivité.
Raison 6. (Pourquoi pas?). Cela peut même vous faire gagner du temps d'écriture, économiser de l'espace disque et même allonger la durée de vie du clavier de votre ordinateur!
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100
Vous avez enregistré 3 lettres, 3 octets, 3 touches supplémentaires au clavier :)
Et enfin, vous pouvez nommer ceux qui déconnent avec des noms réservés comme:
- Utilisateur> LoginUser, AppUser, SystemUser, CMSUser, ...
Ou utilisez les fameux crochets [Utilisateur]
Si vous utilisez des outils de mappage relationnel-objet ou si, à l'avenir, je suggère singulier.
Certains outils, tels que LLBLGen, peuvent automatiquement corriger plusieurs noms, tels que Utilisateurs à Utilisateurs, sans modifier le nom de la table. Pourquoi est-ce important? Parce que quand il est mappé, vous voulez qu'il ressemble à User.Name au lieu de Users.Name ou pire encore de certaines de mes anciennes tables de bases de données nommant tblUsers.strName, ce qui confond simplement le code.
Ma nouvelle règle est de juger de son apparence une fois converti en objet.
une table que j'ai trouvée qui ne correspond pas à la nouvelle dénomination que j'utilise est UsersInRoles. Mais il y aura toujours ces quelques exceptions et même dans ce cas, il semble bien que UsersInRoles.Username.
Je préfère utiliser le nom non infligé, qui en anglais se trouve au singulier.
Infléchir le numéro du nom de la table pose des problèmes orthographiques (comme le montrent de nombreuses autres réponses), mais le choix de procéder de la sorte car les tables contenant généralement plusieurs lignes est également sémantiquement rempli de trous. Ceci est plus évident si nous considérons une langue qui influe sur les noms en fonction de la casse (comme le font la plupart):
Puisque nous faisons habituellement quelque chose avec les lignes, pourquoi ne pas mettre le nom dans l'accusatif? Si nous avons une table sur laquelle nous écrivons plus que ce que nous lisons, pourquoi ne pas mettre le nom en datif? C'est un tableau de quelque chose, pourquoi ne pas utiliser le génitif? Nous ne le ferions pas, car la table est définie comme un conteneur abstrait qui existe indépendamment de son état ou de son utilisation. Infléchir le nom sans raison sémantique précise et absolue, c'est du babillage.
L'utilisation du nom non-réfléchi est simple, logique, régulière et indépendante de la langue.
Quelle convention exige que les tables aient des noms singuliers? J'ai toujours pensé qu'il s'agissait de noms pluriels.
Un utilisateur est ajouté à la table Utilisateurs.
Ce site accepte:
http://vyaskn.tripod.com/object_naming.htm#Tables
Ce site n'est pas d'accord (mais je ne suis pas d'accord):
http://justinsomnia.org/writings/naming_conventions.html
Comme d'autres l'ont mentionné: ce ne sont que des lignes directrices. Choisissez une convention qui fonctionne pour vous et votre entreprise/projet et respectez-la. Basculer entre des mots singuliers et pluriels ou parfois abréger et parfois non, est beaucoup plus aggravant.
Que diriez-vous de cela comme un exemple simple:
SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"
vs.
SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"
Le SQL dans le dernier est plus étrange que le premier.
Je vote pour singulier.
Je suis fermement convaincu que, dans un diagramme de relation d'entité, l'entité doit être reflétée avec un nom singulier, similaire à un nom de classe étant singulier. Une fois instancié, le nom reflète son instance. Donc, avec les bases de données, l'entité transformée en table (un ensemble d'entités ou d'enregistrements) est plurielle. Entité, utilisateur est transformé en utilisateurs de table. Je suis d’accord avec d’autres qui ont suggéré que le nom d’utilisateur puisse être amélioré en employé ou quelque chose de plus applicable à votre scénario.
Cela a plus de sens dans une instruction SQL car vous effectuez une sélection dans un groupe d'enregistrements et si le nom de la table est singulier, la lecture est mauvaise.
Je m'en tiens à singulier pour les noms de table et toute entité de programmation.
La raison? Le fait qu'il existe des pluriels irréguliers en anglais tels que souris ⇒ souris et moutons ⇒ moutons . Ensuite, si j’ai besoin d’une collection , j’utilise simplement des souris ou Moutons , et passer à autre chose.
Cela aide vraiment la pluralité à se distinguer, et je peux facilement et par programme déterminer à quoi ressemblerait la collection de choses.
Donc, ma règle est la suivante: tout est singulier, chaque collection de choses est singulière avec un s ajouté. Aide aussi avec les ORM.
Singulier. Je n'achète pas d'argument impliquant ce qui est le plus logique - chaque personne pense que sa propre préférence est le plus logique. Peu importe ce que vous faites, c'est un gâchis, il suffit de choisir une convention et de s'y tenir. Nous essayons de mapper une langue avec une grammaire et une sémantique très irrégulières (langue parlée et écrite normale) à une grammaire très régulière (SQL) avec une sémantique très spécifique.
Mon principal argument est que je ne considère pas les tables comme un ensemble, mais comme des relations.
Ainsi, la relation AppUser indique les entités qui sont AppUsers.
La relation AppUserGroup me dit quelles entités sont AppUserGroups
La relation AppUser_AppUserGroup me dit en quoi les relations entre AppUsers et AppUserGroups sont liées.
La relation AppUserGroup_AppUserGroup me dit comment AppUserGroups et AppUserGroups sont liés (c'est-à-dire des groupes membres de groupes).
En d'autres termes, lorsque je pense aux entités et à leur relation, je pense aux relations au singulier, mais bien sûr, lorsque je pense aux entités dans des collections ou des ensembles, les collections ou les ensembles sont au pluriel.
Dans mon code, et dans le schéma de base de données, j'utilise le singulier. Dans les descriptions textuelles, je finis par utiliser le pluriel pour améliorer la lisibilité - puis utiliser des polices de caractères, etc. pour distinguer le nom de la table/relation du pluriel s.
J'aime penser que c'est compliqué, mais systématique - et ainsi, il y a toujours un nom généré systématiquement pour la relation que je souhaite exprimer, ce qui pour moi est très important.
IMHO, les noms de table doivent être pluriel comme Clients .
Les noms de classe doivent être au singulier comme Client s’il correspond à une ligne des clients table.
Je voudrais aussi aller avec pluriels, et avec le dilemme susmentionné Utilisateurs , nous adoptons l'approche du crochet.
Nous faisons cela pour assurer l’uniformité entre l’architecture de base de données et l’architecture d’application, en comprenant que la table Users est un ensemble de Utilisateur valeurs autant qu'une collection Utilisateurs dans un artefact de code est une collection de Utilisateur objets.
Le fait que notre équipe de données et nos développeurs parlent le même langage conceptuel (bien que les noms des objets ne soient pas toujours les mêmes) facilite la communication des idées entre elles.
Personnellement, je préfère utiliser des noms au pluriel pour représenter un ensemble, cela "sonne" mieux dans mon esprit relationnel.
À ce moment précis, j'utilise des noms singuliers pour définir un modèle de données pour mon entreprise, car la plupart des employés se sentent plus à l'aise avec ce dernier. Parfois, il vous suffit de simplifier la vie de chacun au lieu d'imposer vos préférences personnelles. (c'est comme ça que j'ai fini dans ce fil, pour avoir une confirmation de ce que devrait être la "meilleure pratique" pour nommer les tables)
Après avoir lu tous les arguments dans ce fil, je suis arrivé à une conclusion:
J'aime mes crêpes au miel, peu importe la saveur préférée de tout le monde. Mais si je cuisine pour d'autres personnes, je vais essayer de leur servir quelque chose qu'ils aiment.
Singulier. J'appellerais un tableau contenant un tas d'objets de représentation de ligne utilisateur 'utilisateurs', mais le tableau est 'le tableau utilisateur'. Penser que la table n'est rien d'autre que l'ensemble des lignes qu'elle contient est erroné, IMO; la table est la métadonnée et l'ensemble des lignes est attaché de manière hiérarchique à la table, ce n'est pas la table elle-même.
J'utilise des ORM tout le temps, bien sûr, et cela aide que le code ORM écrit avec des noms de table pluriels ait l'air stupide.
Je n'aime pas les noms de table au pluriel car certains noms anglais ne sont pas dénombrables (eau, soupe, argent) ou le sens change lorsque vous le rendez dénombrable (poulet vs poulet, viande vs oiseaux). Je n'aime pas aussi utiliser des abréviations pour le nom de la table ou de la colonne, car cela ajoute une pente supplémentaire à la courbe d'apprentissage déjà abrupte.
Ironiquement, je pourrais faire de User une exception et l'appeler Users à cause de SER (Transac-SQL) , parce que moi aussi je n'aime pas utiliser des crochets autour des tables pas besoin.
J'aime aussi nommer toutes les colonnes d'ID comme Id, pas ChickenId ou ChickensId (que font les gars au pluriel à ce sujet?).
Tout cela parce que je ne respecte pas suffisamment les systèmes de base de données, je ne fais que réappliquer les connaissances d'un tour de poney de OO conventions de dénomination telles que Java's par habitude et paresse . J'aimerais qu'il y ait un meilleur support IDE pour le SQL compliqué.
Nous appliquons des normes similaires. Lors de la création de scripts, nous demandons [] autour des noms et, le cas échéant, des qualificatifs de schéma - ils couvrent principalement vos paris contre les futures attaques de noms par la syntaxe SQL.
SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'
Cela a sauvé nos âmes dans le passé - certains de nos systèmes de base de données fonctionnent depuis plus de 10 ans de SQL 6.0 à SQL 2005 - bien au-delà de leur durée de vie prévue.
En fait, j'ai toujours pensé que c'était une convention populaire d'utiliser des noms de table pluriels. Jusqu'à présent, j'ai toujours utilisé le pluriel.
Je peux comprendre l’argument des noms de table singuliers, mais pour moi pluriel a plus de sens. Un nom de table décrit généralement ce que la table contient. Dans une base de données normalisée, chaque table contient des ensembles de données spécifiques. Chaque ligne est une entité et la table contient de nombreuses entités. Ainsi, la forme plurielle du nom de la table.
Un tableau de voitures aurait le nom voitures et chaque ligne est une voiture. J'admets que spécifier la table avec le champ de manière table.field est la meilleure pratique et qu'il est plus lisible d'avoir des noms de table singuliers. Cependant, dans les deux exemples suivants, le premier est plus logique:
SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'
Honnêtement, je vais repenser ma position sur la question et je me fierais aux conventions utilisées par l’organisation pour laquelle je travaille. Cependant, je pense que pour mes conventions personnelles, je vais m'en tenir à des noms de table au pluriel. Pour moi, cela a plus de sens.
Je suis un fan des noms de table singuliers car ils facilitent la lecture de mes diagrammes ER à l'aide de la syntaxe CASE, mais en lisant ces réponses, j'ai l'impression que cela ne m'a jamais très bien compris? Personnellement, je l'aime. Il existe une bonne vue d'ensemble avec des exemples de lisibilité de vos modèles lorsque vous utilisez des noms de table uniques, ajoutez des verbes d'action à vos relations et formez de bonnes phrases pour chaque relation. Tout cela est un peu excessif pour une base de données de 20 tables, mais si vous avez une base de données avec des centaines de tables et une conception complexe, comment vos développeurs le comprendront-ils sans un diagramme lisible?
http://www.aisintl.com/case/method.html
En ce qui concerne les tables et les vues préfixées, je déteste absolument cette pratique. Ne donnez aucune information à une personne avant de lui donner éventuellement une mauvaise information. Toute personne cherchant des objets dans une base de données peut très facilement distinguer une table d'une vue, mais si j'ai une table nommée tblUsers, je décide de la restructurer pour la rendre future en deux tables, avec une vue les unifiant pour ne pas supprimer l'ancien code. J'ai maintenant une vue nommée tblUsers. À ce stade, il me reste deux options peu attrayantes, laissez une vue nommée avec un préfixe tbl qui risque de dérouter certains développeurs, ou forcez une autre couche, couche intermédiaire ou application, à être réécrite pour faire référence à ma nouvelle structure ou à un nouveau nom de vue. Cela annule une grande partie de la valeur des vues à mon humble avis.
Tables: pluriel
Plusieurs utilisateurs sont répertoriés dans le tableau des utilisateurs.
Modèles: singulier
Un utilisateur singulier peut être sélectionné dans la table des utilisateurs.
Contrôleurs: pluriel
http://myapp.com/users listerait plusieurs utilisateurs.
C'est ce que je pense de toute façon.
Le système tables/views du serveur lui-même (SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) sont presque toujours pluriels. Je suppose que par souci de cohérence, je suivrais leur exemple.
Alternatives possibles:
- Renommez la table SystemUser
- Utilisez des crochets
- Conservez les noms de table au pluriel.
L’utilisation de crochets par l’OMI est techniquement l’approche la plus sûre, même si elle est un peu lourde. OMI, c'est 6 sur un, une demi-douzaine sur l'autre, et votre solution se résume à une préférence personnelle/d'équipe.
C'est peut-être un peu redondant, mais je suggérerais d'être prudent. Ce n'est pas forcément une mauvaise chose de renommer les tables, mais la normalisation n'est que cela. un standard - cette base de données est peut-être déjà "normalisée", même si elle est mauvaise :) - Je suggérerais que la cohérence soit un meilleur objectif étant donné que cette base de données existe déjà et qu'elle contient probablement plus de 2 tables.
À moins que vous ne puissiez normaliser toute la base de données, ou du moins que vous envisagiez de travailler à cette fin, je suppose que les noms de table ne sont que la partie visible de l'iceberg. votre meilleur intérêt -
La cohérence pratique est parfois le meilleur standard ... :)
my2cents ---
Ma prise est en sémantique en fonction de la façon dont vous définissez votre conteneur. Par exemple, un "sac de pommes" ou tout simplement "pommes" ou un "sac Apple" ou "Apple".
Exemple: un tableau "college" peut contenir 0 collège ou plus, un tableau "collèges" peut contenir 0 collège ou plus
a "student" table can contain 0 or more students
a table of "students" can contain 0 or more students.
Ma conclusion est que l’un ou l’autre va bien, mais vous devez définir la façon dont vous (ou les personnes qui interagissent avec cela) allez vous approcher lorsque vous vous référez aux tableaux; "une table x" ou une "table de xs"
Si nous regardons les tables système MS SQL Server's, leurs noms, tels qu’ils ont été attribués par Microsoft, sont dans plural.
Les tables système d'Oracle sont nommées dans singular. Bien que quelques-uns d'entre eux soient au pluriel. Oracle recommande le pluriel pour les noms de table définis par l'utilisateur. Cela n'a pas beaucoup de sens qu'ils recommandent une chose et en suivent une autre. Que les architectes de ces deux géants du logiciel aient nommé leurs tables en utilisant des conventions différentes n'a pas beaucoup de sens non plus ... Après tout, quels sont ces gars-là ... PhD?
Je me souviens que dans le monde universitaire, la recommandation était singulière.
Par exemple, quand on dit:
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
peut-être que b/c chaque ID est sélectionné dans une rangée particulière ...?
J'ai toujours utilisé singulier simplement parce que c'est ce que l'on m'a appris. Cependant, tout en créant un nouveau schéma récemment, pour la première fois depuis longtemps, j'ai activement décidé de maintenir cette convention simplement parce que ... elle est plus courte. Ajouter un "s" à la fin de chaque nom de table me semble aussi inutile que d'ajouter "tbl_" devant tout le monde.
Je pense que l’utilisation du singulier est ce qui nous a été enseigné à l’université. Mais en même temps, vous pourriez affirmer que, contrairement à la programmation orientée objet, une table n'est pas une instance de ses enregistrements.
Je pense que je penche en faveur du singulier pour le moment en raison d'irrégularités plurielles en anglais. En allemand, c'est encore pire en raison de l'absence de formes plurielles cohérentes. Parfois, vous ne pouvez pas savoir si un mot est pluriel ou non sans l'article de spécification qui le précède (der/die/das). Et dans les langues chinoises, il n’ya de toute façon pas de formes plurielles.
Comme d'autres l'ont mentionné ici, les conventions devraient constituer un outil permettant d'améliorer la facilité d'utilisation et la lisibilité. Pas comme une manille ou un club pour torturer les développeurs.
Cela dit, ma préférence personnelle est d’utiliser des noms singuliers pour les tables et les colonnes. Cela vient probablement de mon contexte de programmation. Les noms de classe sont généralement singuliers sauf s’ils constituent une sorte de collection. Dans mon esprit, je suis en train de stocker ou de lire des enregistrements individuels dans la table en question, donc le singulier a un sens pour moi.
Cette pratique me permet également de réserver plusieurs noms de table à ceux qui stockent des relations plusieurs à plusieurs entre mes objets.
J'essaie également d'éviter les mots réservés dans les noms de table et de colonne. Dans le cas en question ici, il est plus logique d'aller à l'encontre de la convention singulière pour les utilisateurs afin d'éviter la nécessité d'encapsuler une table qui utilise le mot réservé d'utilisateur.
J'aime utiliser les préfixes de manière limitée (tbl pour les noms de table, sp_ pour les noms de proc, etc.), bien que beaucoup croient que cela ajoute de l'encombrement. Je préfère également les noms CamelBack aux traits de soulignement, car je finis toujours par appuyer sur le + au lieu de _ lorsque vous tapez le nom. Beaucoup d'autres ne sont pas d'accord.
Voici un autre bon lien pour les directives de convention de nommage: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/ =
Rappelez-vous que le facteur le plus important dans votre convention est que cela a du sens pour les personnes qui interagissent avec la base de données en question. Il n'y a pas de "sonnerie unique pour tout contrôler" en ce qui concerne les conventions de dénomination.
J'ai toujours pensé que c'était une convention idiote. J'utilise plusieurs noms de table.
(Je crois que la raison derrière cette politique est de faciliter la production de classes d'objet et de collection par les générateurs de code ORM, car il est plus facile de produire un nom au pluriel à partir d'un nom singulier que l'inverse.)
Une fois, j'ai utilisé "Mec" pour la table des utilisateurs - même nombre court de caractères, pas de conflit avec les mots-clés, toujours une référence à un humain générique. Si je ne m'étais pas inquiété des têtes bouchées qui pourraient voir le code, je l'aurais gardé comme ça.
J'utilise uniquement des noms pour les noms de table orthographiés de la même manière, au singulier ou au pluriel:
orignal poisson cerf avion vous pantalons shorts lunettes lunettes ciseaux espèces progéniture
Les directives sont vraiment là pour ça. Ce n'est pas "immuable", c'est pourquoi vous avez la possibilité de les ignorer.
Je dirais qu'il est plus intuitif logiquement d'avoir des noms de table pluralisés. Une table est un ensemble d'entités après tout. En plus des alternatives mentionnées, je vois couramment des préfixes sur les noms de table ...
- tblUser
- tblCe
- tbl
- tblTheOther
Je ne suggère pas que c'est la voie à suivre, je vois aussi des espaces utilisés BEAUCOUP dans les noms de table que je déteste. J'ai même rencontré des noms de champs avec des personnages idiots comme? comme pour dire que ce champ répond à une question.
Je vais juste donner mon avis, pourquoi j'utilise singulier noms.
Par exemple, je dois obtenir tous les champs d'un utilisateur:
-- Select every fields from 'user' table
SELECT * FROM user
J'ai besoin du nom de l'utilisateur de 21 ans:
-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'
Bien sûr, le pluriel peut être utilisé de la même manière, mais pour que mon cerveau puisse lire, je pense vraiment que c'est la bonne façon de faire.
La définition SQL d'une table est en réalité la définition d'une ligne potentielle de la table, pas la collection. Par conséquent, le nom utilisé dans cette définition doit désigner le type de la ligne, pas le nom de la collection. Les personnes qui préfèrent le pluriel parce que les déclarations en anglais se lisent bien doivent commencer à penser de manière plus logique et se pencher sur toute la logique et le code de programmation impliqués dans l’utilisation réelle d’un tableau. Il existe plusieurs très bonnes raisons mentionnées dans ces commentaires pour utiliser des noms de table singuliers. Celles-ci incluent de très bonnes raisons de NE PAS utiliser plusieurs noms de table. "Bien lire" ne devrait pas être une raison du tout, d'autant plus que certains peuvent lire l'idée différemment.
Si vous y allez, il y aura des problèmes, mais si vous restez, ce sera le double.
Je préférerais de loin aller contre certaines conventions de nommage supposées non plurielles plutôt que de nommer ma table après quelque chose qui pourrait être un mot réservé.
Je ne l'ai pas vu clairement dans aucune des réponses précédentes. Beaucoup de programmeurs n'ont pas de définition formelle en tête lorsqu'ils travaillent avec des tables. Nous communiquons souvent de manière intuitive en termes de "enregistrements" ou de "lignes". Cependant, à quelques exceptions près pour les relations dénormalisées, les tables sont généralement conçues de manière à ce que la relation entre les attributs non-clé et la clé constitue une fonction théorique d'ensemble.
Une fonction peut être définie comme un sous-ensemble d'un produit croisé entre deux ensembles, dans lequel chaque élément de l'ensemble de clés apparaît au plus une fois dans le mappage. Par conséquent, la terminologie découlant de cette perspective tend à être singulière. On retrouve la même convention singulière (ou au moins non plurielle) dans d'autres théories mathématiques et informatiques faisant intervenir des fonctions (algèbre et calcul lambda, par exemple).
J'utilise toujours des noms de table singuliers mais, comme déjà indiqué, le plus important est d'être cohérent et d'utiliser le même formulaire pour tous les noms.
Ce que je n’aime pas avec les noms de table pluriels, c’est que les noms combinés peuvent devenir assez étranges. Si, par exemple, vous avez une table nommée Users et que vous souhaitez stocker des propriétés pour l'utilisateur, vous obtiendrez une table nommée UsersProperties...
Si vous utilisez certains frameworks tels que Zend Framework (PHP), il est conseillé d'utiliser le pluriel pour les classes de table et le singulier pour les classes de ligne.
Supposons donc que vous créez un objet de table $ utilisateurs = nouveaux utilisateurs () et que vous ayez déclaré la classe de lignes comme utilisateur, vous pourrez également appeler un nouvel utilisateur ().
Maintenant, si vous utilisez singular pour les noms de table, vous devrez faire quelque chose comme new UserTable () avec la ligne étant new UserRow (). Cela me semble plus maladroit que d'avoir simplement un objet Users () pour la table et User () pour les lignes.
Il n'y a pas de "convention" exigeant que les noms de table soient singuliers.
Par exemple, nous avions une table appelée "REJECTS" sur une base de données utilisée par un processus d’évaluation, contenant les enregistrements rejetés d’une exécution du programme, et je ne vois aucune raison de ne pas utiliser le pluriel pour cela. table (le nommer "REJECT" aurait été simplement amusant ou trop optimiste).
À propos de l’autre problème (guillemets), cela dépend du dialecte SQL. Oracle ne nécessite pas de guillemets autour des noms de table.
Il y a différents articles sur les deux sites, je pense que vous n'avez qu'à choisir votre camp. Personnellement, je préfère Plurar pour nommer les tables, et bien sûr singulier pour nommer les colonnes.
J'aime comment vous pouvez lire ceci:
SELECT CustomerName FROM Customers WHERE CustomerID = 100;
Nous avons vraiment la POO et c'est formidable, mais la plupart des gens continuent à utiliser des bases de données relationnelles, pas de bases de données objet. Il n'est pas nécessaire de suivre les concepts OOP pour les bases de données relationnelles.
Un autre exemple, vous avez une table Teams, qui conserve TeamID, TeamColor mais également PlayerID, et qui aura les mêmes teamID et TeamColor pour une certaine quantité de PlayerID ...
A quelle équipe appartient le joueur?
SELECT * FROM Teams WHERE PlayerID = X
Tous les joueurs de l'équipe X?
SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X
Tout ça sonne bien pour toi?
Quoi qu'il en soit, jetez également un coup d'œil aux conventions de dénomination utilisées par W3Schools:
Un nom TABLE est UNE définition de la structure d'une table. Un nom VIEW ou QUERY correspond à UNE définition d'une vue ou requête de (une ou plusieurs) tables. Une table, une vue ou une requête peut contenir l’un des éléments suivants:
0 enregistrements 1 enregistrement Plusieurs enregistrements.
Pourquoi voudriez-vous mettre un 's' à la fin d'un nom d'objet unique? Que voulez-vous signifier en plaçant ce "s" à la fin d'un nom d'objet?
Si vous souhaitez vous différencier, ajoutez "_tbl". Une vue est '_vew' (pas la convention idiote '_v').
Suffixe minimum de 3 caractères - cela met fin à la discussion.
Une table est un objet de base de données - pas différent des autres.
L'enregistrement de 3 caractères n'enregistre que la clarté du sens.
Rouge ;-)
En cherchant une bonne convention de nommage, la confusion suivante se produit, comme je devrais nommer:
1) acc. à ce que la table tient par exemple: Une table d'utilisateurs. Ça va toujours être au pluriel. Donc, tilisateurs
2) acc. --- Quel enregistrement enregistrement Exemple: un enregistrement dans les tables des utilisateurs sera un utilisateur unique. SO, tilisateur.
Maintenant, le problème pour users_roles principalement. cas 1: acc. à la première convention de nommage, users_roles Ce que ce nom suggère, les utilisateurs et leurs rôles.
cas 2: acc. selon la seconde convention de nommage, user_role Ce que ce nom suggère, utilisateur et ses rôles.
ne bonne convention de nommage consiste à donner une idée supplémentaire des relations d'entité , en particulier lorsque plusieurs relations sont stockées.
Ici, selon le scénario, nous devrions identifier des ensembles d’informations.
Dans la table users, tous les ensembles formés sont des utilisateurs uniques. Dans la table Roles, tous les ensembles formés sont des rôles uniques. Dans la table de relations utilisateur et rôles, des ensembles d'utilisateurs peuvent être formés avec différents rôles, ce qui donne une idée de relations 1-plusieurs stockées.
I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles
J'ai résolu le même problème en nommant la table "Employé" (en réalité "Employés"). J'essaie de rester aussi loin que possible de tout conflit avec des mots éventuellement réservés. Même les "utilisateurs" sont trop proches pour moi.