Question Dilemme de dénomination de tableau: Noms singuliers ou pluriels [fermé]


Selon l'Académie, les noms de table devraient être le singulier de l'entité qu'ils stockent.

Je n'aime pas les T-SQL qui nécessitent des crochets autour des noms, mais j'ai renommé Users tableau au singulier, condamnant à perpétuité ceux qui utilisent la table pour parfois utiliser des crochets.

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

Dois-je rester ou dois-je partir?


1171


origine


Réponses:


D'autres ont donné de très bonnes réponses en ce qui concerne les "standards", mais je voulais simplement ajouter ceci ... Est-il possible que "User" (ou "Users") ne soit pas une description complète des données contenues dans le tableau ? Non pas que vous deviez devenir 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é.


206



J'ai eu 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 si contient 0, 1 ou un million de pommes, c'est toujours le même sac. Les tableaux 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 est plus sur un langage parlé (en fait, pour déterminer s'il y en a un 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, mais ils auront toujours un singulier (à quelques exceptions près comme News).

  • Client
  • Commande
  • Utilisateur
  • Statut
  • Nouvelles

Raison 3. (Esthétique et Ordre). Spécialement 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 deuxième):

  • 1.Order
  • 2.OrderDetail

Par rapport à:

  • 1.OrderDétails
  • 2.Ordres

Raison 4 (Simplicité). Mettre tous ensemble, noms de table, clés primaires, relations, 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, singulier-pluriel-maître-détail .. .)

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

Une fois que vous savez que vous avez affaire à "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 devient plus petit, 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 de langue anglaise non-native de penser à "Repository" que de "Repositories", ou "Statuses" au lieu de "Status". Avoir des noms singuliers peut conduire à moins d'erreurs causées par les fautes de frappe, gagner du temps en n'ayant pas à penser "est-ce enfant ou enfant?", D'où une amélioration de la productivité.

Raison 6. (Pourquoi pas?). Il peut même vous faire gagner du temps, économiser de l'espace disque et même faire durer le clavier de votre ordinateur plus longtemps!

  • 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 gâchent avec des noms réservés comme:

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

Ou utilisez les crochets infâmes [Utilisateur]


1385



Si vous utilisez les outils Object Relational Mapping ou que je vous proposerai à l'avenir Singulier.

Certains outils tels que LLBLGen peuvent automatiquement corriger plusieurs noms comme Utilisateurs à 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 de certaines de mes anciennes tables de bases de données nommant tblUsers.strName qui est juste confus dans le code.

Ma nouvelle règle consiste à juger de ce à quoi il ressemblera une fois qu'il aura été 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, il semble bien comme UsersInRoles.Username.


242



Je préfère utiliser le sans réflexion nom, qui en anglais se trouve être singulier.

Affecter le numéro du nom de la table provoque des problèmes orthographiques (comme le montrent la plupart des autres réponses), mais choisir de le faire parce que les tables contiennent généralement plusieurs lignes est également sémantiquement plein de trous. Ceci est plus évident si l'on considère un langage qui infléchit les noms en fonction du cas (comme le font la plupart):

Puisque nous faisons habituellement quelque chose avec les lignes, pourquoi ne pas mettre le nom dans le cas accusatif? Si nous avons une table à laquelle nous écrivons plus que ce que nous lisons, pourquoi ne pas mettre le nom en datif? C'est une table de quelque chose, pourquoi ne pas utiliser le génitif? Nous ne ferions pas cela, car la table est définie comme un conteneur abstrait qui existe quel que soit son état ou son utilisation. Infléchir le nom sans raison sémantique précise et absolue, c'est babiller.

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


174



Quelle convention exige que les tables aient des noms singuliers? J'ai toujours pensé que c'était plusieurs noms.

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. Passer du singulier au pluriel ou parfois abréger des mots et parfois non est beaucoup plus agaçant.


115



Que diriez-vous de ceci 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 le dernier est un son étrange que l'ancien.

Je vote pour singulier.


55



Je suis fermement convaincu que dans un diagramme de relation d'entité, l'entité devrait être reflétée avec un nom singulier, semblable à 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 une table (une collection d'entités ou d'enregistrements) est plurielle. Entité, l'utilisateur est transformé en utilisateurs de table. Je suis d'accord avec d'autres qui ont suggéré que peut-être le nom de l'utilisateur pourrait être amélioré à l'employé ou quelque chose de plus applicable à votre scénario.

Cela a plus de sens dans une instruction SQL car vous sélectionnez un groupe d'enregistrements et si le nom de la table est singulier, il ne se lit pas correctement.


53



Je colle avec 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'un collection, je viens d'utiliser des souris ou des moutons, et avance.

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: tout est singulier, chaque collection de choses est singulière avec un s ajouté Aide avec les ORM aussi.


35



Singulier. Je n'achète aucun argument impliquant le plus logique - tout le monde pense que sa préférence est la plus logique. Peu importe ce que vous faites, c'est un gâchis, choisissez une convention et respectez-la. Nous essayons de mapper une langue avec une grammaire et une sémantique très irrégulière (langage parlé et écrit normal) à une grammaire (régulière) très régulière 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.

Alors le AppUser relation indique quelles entités sont AppUsers.

le AppUserGroup relation me dit quelles entités sont AppUserGroups

le AppUser_AppUserGroup relation me dit comment le AppUsers et AppUserGroups sont liés.

le AppUserGroup_AppUserGroup relation me dit comment AppUserGroups et AppUserGroups sont liés (c'est-à-dire des groupes de groupes).

En d'autres termes, quand je pense aux entités et à la manière dont elles sont liées, je pense aux relations au singulier, mais bien sûr, quand je pense aux entités dans les collections ou les ensembles, les collections ou les ensembles sont pluriels.

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

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 est très important pour moi.


29



J'irais aussi avec pluriels, et avec les précités Utilisateurs dilemme, nous adoptons l'approche du crochetage.

Nous faisons ceci pour fournir l'uniformité entre l'architecture de base de données et l'architecture d'application, avec la compréhension sous-jacente que le Utilisateurs table est une collection de Utilisateur des valeurs autant qu'un Utilisateurs la collecte dans un artefact de code est une collection de Utilisateur objets.

Avoir notre équipe de données et nos développeurs parlant le même langage conceptuel (même si ce n'est pas toujours le même nom d'objet) facilite le transfert d'idées entre eux.


19



À mon humble avis, les noms de table devraient être pluriel comme Les clients.

Les noms de classe doivent être singuliers comme Client si elle correspond à une ligne dans le Les clients table.


17