Dilemme de dénomination des tableaux: noms singuliers ou pluriels [fermé]

Le monde universitaire veut que les noms de table soient le singulier de l'entité dont ils stockent les attributs.

Je n'aime pas tout T-SQL qui nécessite des crochets autour des noms, mais j'ai renommé une Userstable au singulier, condamnant à jamais ceux qui utilisent la table à parfois utiliser des crochets.

Mon intuition est qu'il est plus correct de rester avec le singulier, mais mon intuition est également que les parenthèses indiquent les indésirables comme les noms de colonne avec des espaces, etc.

Dois-je rester ou dois-je partir?

D'autres ont donné de très 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 en fait une description complète des données contenues dans le tableau ? Non pas que vous deveniez trop fou avec les noms de table et la spécificité, mais peut-être quelque chose comme "Widget_Users" (où "Widget" est le nom de votre application ou site Web) serait plus approprié.

J'avais la même question, et après avoir lu toutes les réponses ici, je reste définitivement avec SINGULAR, raisons:

Raison 1 (Concept). Vous pouvez penser à un sac contenant des pommes comme "AppleBag", peu importe s'il contient 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'il contient, pas la quantité de données qu'il contient. De plus, le concept pluriel est davantage une langue parlée (en fait pour déterminer s'il y en a une ou plusieurs).

Raison 2 . (Commodité). il est plus facile de sortir avec des noms singuliers qu'avec des noms pluriels. Les objets peuvent avoir des pluriels irréguliers ou pas du tout pluriels, mais auront toujours un pluriel (à quelques exceptions près comme News).

• Client
• Ordre
• Utilisateur
• Statut
• Nouvelles

Raison 3 . (Esthétique et ordre). Surtout dans les scénarios maître-détail, cela se lit mieux, s'aligne mieux par nom et a un ordre plus logique (maître d'abord, détail ensuite):

• 1.Ordre
• 2.OrderDetail

Par rapport à:

• 1.OrderDetails
• 2.Commandes

Raison 4 (simplicité). Ensemble, les noms de table, les clés primaires, les relations, les classes d'entités ... est préférable de ne connaître qu'un seul nom (singulier) au lieu de deux (classe singulière, table plurielle, champ singulier, maître-détail singulier-pluriel .. .)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

Une fois que vous savez que vous traitez avec le «client», vous pouvez être sûr que vous utiliserez le même mot pour tous vos besoins d'interaction avec la base de données.

Raison 5 . (Mondialisation). Le monde se rétrécit, vous pouvez avoir une équipe de différentes nationalités, tout le monde n'a pas l'anglais comme langue maternelle. Il serait plus facile pour un programmeur non natif de langue anglaise de penser à "Repository" plutôt qu'à "Repositories", ou "Status" au lieu de "Statuses". 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?). Il peut même vous faire gagner du temps d'écriture, économiser de l'espace disque et même prolonger la durée de vie de votre clavier d'ordinateur!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Vous avez enregistré 3 lettres, 3 octets, 3 touches de clavier supplémentaires :)

Et enfin, vous pouvez nommer ceux qui jouent avec des noms réservés comme:

• Utilisateur> LoginUser, AppUser, SystemUser, CMSUser, ...

Ou utilisez les fameux crochets [Utilisateur]

Si vous utilisez des outils de cartographie relationnelle objet ou le ferez à l'avenir, je suggère le singulier .

Certains outils comme LLBLGen peuvent corriger automatiquement plusieurs noms comme Utilisateurs en Utilisateur sans changer le nom de la table elle-même. Pourquoi est-ce important? Parce que quand il est mappé, vous voulez qu'il ressemble à User.Name au lieu de Users.Name ou pire à partir de certaines de mes anciennes tables de bases de données nommant tblUsers.strName, ce qui est tout simplement déroutant dans le code.

Ma nouvelle règle d'or consiste à juger de son aspect une fois converti en objet.

une table que j'ai trouvée qui ne correspond pas au nouveau nom que j'utilise est UsersInRoles. Mais il y aura toujours ces quelques exceptions et même dans ce cas, cela ressemble bien à UsersInRoles.Username.

Je préfère utiliser le nom non infléchi, qui en anglais se trouve être singulier.

Infléchir le numéro du nom de la table provoque des problèmes orthographiques (comme le montrent de nombreuses autres réponses), mais choisir de le faire car les tables contiennent généralement plusieurs lignes est également sémantiquement plein de trous. C'est plus évident si nous considérons une langue qui infléchit les noms en fonction de la casse (comme la plupart le font):

Puisque nous faisons habituellement quelque chose avec les lignes, pourquoi ne pas mettre le nom dans le cas accusatif? Si nous avons un tableau que nous écrivons plus que nous ne lisons, pourquoi ne pas mettre le nom au 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 revient à babiller.

L'utilisation du nom non infléchi est simple, logique, régulière et indépendante de la langue.

Quelle convention exige que les tableaux aient des noms singuliers? J'ai toujours pensé que c'était des 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égés 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"

contre.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

Le SQL dans ce dernier est plus étrange que le premier.

Je vote pour le 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. Ainsi, avec les bases de données, l'entité lorsqu'elle est transformée en table (une collection d'entités ou d'enregistrements) est plurielle. Entité, l'utilisateur est transformé en utilisateurs de table. Je serais d'accord avec d'autres qui ont suggéré que le nom d'utilisateur pourrait être amélioré en employé ou quelque chose de plus applicable à votre scénario.

Cela a alors 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, il ne se lit pas bien.

Je m'en tiens au singulier pour les noms de table et toute entité de programmation.

La raison? Le fait qu'il existe des pluriels irréguliers en anglais comme souris ⇒ souris et mouton ⇒ mouton . Ensuite, si j'ai besoin d'une collection , j'utilise simplement des souris ou des moutons et je continue.

Cela aide vraiment la pluralité à se démarquer, et je peux facilement et par programmation déterminer à quoi ressemblerait la collection de choses.

Donc, ma règle est: tout est singulier, chaque collection de choses est singulière avec un s en annexe. Aide également avec les ORM.

À mon humble avis, les noms de table doivent être pluriels comme les clients .

Les noms de classe doivent être singuliers comme Customer s'ils correspondent à une ligne de la table Customers .

Singulier. Je n'achète aucun argument impliquant ce qui est le plus logique - chaque personne pense que sa propre préférence est la plus logique. Peu importe ce que vous faites, c'est un gâchis, choisissez simplement une convention et respectez-la. Nous essayons de mapper une langue avec une grammaire et une sémantique très irrégulières (langage parlé et écrit normal) à une grammaire très régulière (SQL) avec une sémantique très spécifique.

Mon argument principal est que je ne considère pas les tables comme un ensemble mais comme des relations.

Ainsi, la AppUserrelation indique quelles entités sont AppUsers.

La AppUserGrouprelation me dit quelles entités sontAppUserGroups

La AppUser_AppUserGrouprelation me dit comment le AppUserset AppUserGroupssont liés.

La AppUserGroup_AppUserGrouprelation me dit comment AppUserGroupset AppUserGroupssont liés (c.-à-d. Groupes membres de groupes).

En d'autres termes, quand je pense aux entités et à leurs relations, je pense aux relations au singulier, mais bien sûr, quand je pense aux entités des collections ou des ensembles, les collections ou les ensembles sont pluriels.

Dans mon code, puis, et dans le schéma de base de données, j'utilise singulier. Dans les descriptions textuelles, je finis par utiliser le pluriel pour une meilleure lisibilité - puis j'utilise des polices, etc. pour distinguer le nom de la table / relation du pluriel s.

J'aime à penser que c'est désordonné, mais systématique - et de cette façon, 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.

J'irais également avec des pluriels , et avec le dilemme des utilisateurs susmentionné , nous adoptons l'approche entre crochets.

Nous faisons cela pour assurer l'uniformité entre l'architecture de base de données et l'architecture d'application, avec la compréhension sous-jacente que la table Users est une collection de valeurs User autant qu'une collection Users dans un artefact de code est une collection d' objets User .

Le fait que notre équipe de données et nos développeurs parlent le même langage conceptuel (mais pas toujours les mêmes noms d'objet) facilite la transmission d'idées entre eux.

Je préfère personnellement utiliser des noms pluriels pour représenter un ensemble, cela "sonne" mieux à 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 gens au travail s'y sentent plus à l'aise. Parfois, il suffit de rendre la vie plus facile à tout le monde au lieu d'imposer vos préférences personnelles. (c'est ainsi que je me suis retrouvé dans ce fil, pour obtenir une confirmation sur ce qui devrait être la "meilleure pratique" pour nommer les tables)

Après avoir lu tous les arguments de ce fil, je suis arrivé à une conclusion:

J'aime mes crêpes au miel, quelle que soit la saveur préférée de tout le monde. Mais si je cuisine pour d'autres personnes, j'essaierai de leur servir quelque chose qu'ils aiment.

Singulier. J'appellerais un tableau contenant un groupe d'objets de représentation de lignes d'utilisateurs «utilisateurs», mais la table est «la table des utilisateurs». Penser que la table n'est rien d'autre que l'ensemble des lignes qu'elle contient est faux, OMI; la table est les métadonnées et l'ensemble des lignes est attaché hiérarchiquement à 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 plusieurs noms de table soit stupide.

En fait, j'ai toujours pensé que c'était une convention populaire d'utiliser plusieurs noms de table. Jusqu'à ce point, j'ai toujours utilisé le pluriel.

Je peux comprendre l'argument pour les noms de table singuliers, mais pour moi le pluriel a plus de sens. Un nom de table décrit généralement ce que contient la table. Dans une base de données normalisée, chaque table contient des ensembles spécifiques de données. Chaque ligne est une entité et le tableau contient de nombreuses entités. Ainsi, la forme plurielle du nom de la table.

Une table de voitures aurait le nom de voitures et chaque rangée est une voiture. J'admets que la spécification de la table avec le champ d'une table.fieldmanière est la meilleure pratique et que le fait d'avoir des noms de table singuliers est plus lisible. 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 repenserai ma position sur la question, et je compterais sur les conventions réelles utilisées par l'organisation pour laquelle je développe. Cependant, je pense que pour mes conventions personnelles, je m'en tiendrai aux noms de table pluriels. Pour moi, cela a plus de sens.

Je n'aime pas les noms de table pluriels car certains noms en anglais ne sont pas dénombrables (eau, soupe, argent liquide) ou le sens change lorsque vous le rendez dénombrable (poulet vs un poulet; viande vs oiseau). Je n'aime pas non plus utiliser des abréviations pour le nom de table ou le nom de colonne, car cela ajoute une pente supplémentaire à la courbe d'apprentissage déjà abrupte.

Ironiquement, je pourrais faire Userune exception et l'appeler à Userscause de USER (Transac-SQL) , parce que je n'aime pas non plus utiliser des crochets autour des tables si je n'ai pas à le faire.

J'aime aussi nommer toutes les colonnes ID comme Id, pas ChickenIdou ChickensId(que font les gars au pluriel à ce sujet?).

Tout cela parce que je n'ai pas le respect nécessaire pour les systèmes de base de données, je réapplique simplement les connaissances en un tour des conventions de nommage OO comme Java par habitude et paresse. Je souhaite qu'il y ait un meilleur support IDE pour SQL compliqué.

Nous exécutons des normes similaires, lors de l'écriture de scripts, nous demandons [] autour des noms et, le cas échéant, des qualificatifs de schéma - principalement, il protège vos paris contre les futures saisies de nom 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 ont exécuté plus de 10 ans de SQL 6.0 à SQL 2005 - bien au-delà de leur durée de vie prévue.

Tableaux: 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 répertorie plusieurs utilisateurs.

C'est mon point de vue de toute façon.

Je suis un fan des noms de table singuliers car ils rendent mes diagrammes ER en utilisant la syntaxe CASE plus faciles à lire, mais en lisant ces réponses, j'ai l'impression qu'il n'a jamais très bien compris? Je l'aime personnellement. Il y a un bon aperçu avec des exemples de la lisibilité de vos modèles lorsque vous utilisez des noms de table singuliers, ajoutez des verbes d'action à vos relations et formez de bonnes phrases pour chaque relation. C'est un peu exagéré 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 pourront-ils jamais la comprendre sans un bon diagramme lisible?

http://www.aisintl.com/case/method.html

En ce qui concerne le préfixe des tableaux et des vues, je déteste absolument cette pratique. Ne donnez aucune information à une personne avant de lui donner éventuellement de mauvaises informations. Toute personne parcourant une base de données pour des objets peut assez facilement distinguer une table d'une vue, mais si j'ai une table nommée tblUsers que pour une raison quelconque je décide de restructurer à l'avenir en deux tables, avec une vue les unifiant pour éviter de casser l'ancien code J'ai maintenant une vue nommée tblUsers. À ce stade, je me retrouve avec deux options peu attrayantes, laisser une vue nommée avec un préfixe tbl qui peut confondre certains développeurs, ou forcer une autre couche, niveau intermédiaire ou application à réécrire pour référencer ma nouvelle structure ou nommer viewUsers. Cela annule une grande partie de la valeur des vues à mon humble avis.

Le système tables/viewsdu serveur lui - même ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) sont presque toujours au pluriel. Je suppose que par souci de cohérence, je suivrais leur exemple.

Si nous regardons les MS SQL Server'stables système, leurs noms attribués par Microsoft sont là plural.

Les tables système d'Oracle sont nommées dans singular. Bien que certains d'entre eux soient pluriels. 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, que sont ces gars-là ... PhD?

Je me souviens dans le milieu universitaire, la recommandation était singulière.

Par exemple, lorsque nous disons:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

peut-être que b / c chacun IDest sélectionné dans une seule ligne particulière ...?

Cela peut être un peu redondant, mais je suggère d'être prudent. Pas nécessairement que c'est une mauvaise chose de renommer des tables, mais la normalisation est juste cela; un standard - cette base de données peut déjà être "standardisée", mais mal :) - Je dirais que la cohérence est un meilleur objectif étant donné que cette base de données existe déjà et qu'elle se compose probablement de plus de 2 tables.

À moins que vous ne puissiez standardiser l'ensemble de la base de données, ou du moins que vous envisagiez de travailler à cette fin, je soupçonne que les noms de table ne sont que la pointe de l'iceberg et que la concentration sur la tâche à accomplir, endurant la douleur des objets mal nommés, peut être votre meilleur intérêt -

La cohérence pratique est parfois la meilleure norme ... :)

my2cents ---

Alternatives possibles:

• Renommez la table SystemUser
• Utilisez des supports
• Conservez les noms de table au pluriel.

L'OMI utilisant des supports est techniquement l'approche la plus sûre, bien qu'elle soit un peu lourde. IMO c'est 6 d'un, une demi-douzaine de l'autre, et votre solution se résume vraiment à la préférence personnelle / d'équipe.

Ma prise de position est sémantique selon la façon dont vous définissez votre conteneur. Par exemple, Un "sac de pommes" ou simplement "pommes" ou un "sac de pomme" ou "pomme".

Exemple: une table "college" peut contenir 0 ou plusieurs collèges une table "college" peut contenir 0 ou plusieurs collègues

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Ma conclusion est que c'est bien mais que vous devez définir comment vous (ou les personnes qui interagissent avec lui) allez vous approcher en vous référant aux tableaux; "table ax" ou "table xs"

Comme d'autres l'ont mentionné ici, les conventions devraient être un outil pour accroître 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 expérience en programmation. Les noms de classe sont généralement singuliers à moins qu'ils ne soient une sorte de collection. Dans mon esprit, je stocke ou lit des enregistrements individuels dans le tableau en question, donc le singulier a du 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 des utilisateurs pour éviter d'avoir à encapsuler une table qui utilise le mot réservé de l'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 parce que je finis toujours par frapper le + au lieu de _ lorsque je tape le nom. Beaucoup d'autres ne sont pas d'accord.

Voici un autre bon lien pour nommer les directives de convention: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

N'oubliez pas que le facteur le plus important de votre convention est qu'elle 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 les gouverner tous» lorsqu'il s'agit de conventions de dénomination.

Je pense que l'utilisation du singulier est ce qu'on nous a enseigné à l'université. Mais en même temps, vous pourriez faire valoir 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 en ce 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 dire si un mot est pluriel ou non sans l'article spécifié devant lui (der / die / das). Et dans les langues chinoises, il n'y a de toute façon pas de formes plurielles.

J'ai utilisé une fois "Mec" pour la table utilisateur - 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 n'avais pas été préoccupé par les têtes bouchées qui pourraient voir le code, je l'aurais gardé de cette façon.

J'ai toujours utilisé le singulier simplement parce que c'est ce qu'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 ... c'est plus court. Ajouter un «s» à la fin de chaque nom de table me semble aussi inutile que d'ajouter «tbl_» devant chacun.

J'ai toujours pensé que c'était une convention stupide. J'utilise plusieurs noms de table.

(Je crois que la logique derrière cette politique est qu'elle permet aux générateurs de code ORM de produire plus facilement des classes d'objets et de collections, car il est plus facile de produire un nom pluriel à partir d'un nom singulier que vice-versa)

J'utilise uniquement des noms pour mes noms de table qui sont orthographiés de la même manière, qu'ils soient au singulier ou au pluriel:

orignal poisson cerf avion vous pantalon shorts lunettes ciseaux espèce progéniture

Je n'ai vu cela clairement exprimé dans aucune des réponses précédentes. De nombreux programmeurs n'ont aucune définition formelle en tête lorsqu'ils travaillent avec des tables. Nous communiquons souvent de manière intuitive en termes d '"enregistrements" ou de "lignes". Cependant, à quelques exceptions près pour les relations dénormalisées, les tables sont généralement conçues de sorte que la relation entre les attributs non clés 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 se produit au plus une fois dans le mappage. Par conséquent, la terminologie issue de cette perspective a tendance à être singulière. On voit la même convention singulière (ou du moins non plurielle) à travers d'autres théories mathématiques et informatiques impliquant des fonctions (algèbre et calcul lambda par exemple).