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

1468

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?

sql sql-server naming-conventions

— ProfK
source

Dup des noms de tables de base de données précédents , au pluriel ou au singulier , mais celui-ci a attiré plus d'attention.

— 2012

7

Je suis surpris que plus de gens ne disent pas: c'est déterminé par ce que représente une seule ligne. Dans une base de données unique, je peux avoir une table dont les lignes représentent un seul widget, et une autre qui a une relation un-à-plusieurs avec cette table signifie que les lignes représentent de nombreux widgets. Ne pas le faire perd son expressivité.

— andygavin

1

Je veux juste ajouter que dans toutes ces discussions, veuillez noter qu'un tableau ne forme en aucune façon ou ne ressemble pas à une classe. Une table est une collection d'éléments d'un type spécifique qui peuvent être triés, interrogés, etc. sur des propriétés individuelles. Une classe est le cadre pour décrire les propriétés et le comportement d'un type spécifique. En termes de codage OO, la représentation fermée d'une table est une collection d'objets (quel que soit l'ORM que vous utilisiez). C'est de loin la réponse google la mieux classée à ce sujet, donc bien que la question soit fermée, la page a toujours de la valeur.

1

Je choisirais la pratique courante de l'écosystème dans lequel vous travaillez. Par exemple: dans Node.js, les ORM comme Bookshelf.js ou Objection.js sont principalement basés sur "Knex.js". Et dans la documentation "Knex.js" vous trouverez des noms de table au pluriel. Je choisirais donc le pluriel dans ce domaine. Source: knexjs.org/#Schema-createTable

— Benny Neugebauer

2

Oui je suis d'accord. Il est logique d'avoir une table d'utilisateurs et de l'appeler "AppUser" en même temps, il est également logique d'avoir une table de règles applicables à un type particulier d'utilisateur et de l'appeler "UserRules"

— Arindam

242

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é.

— Tom H
source

7

Je suis d'accord. OrgUsers, AppUsers, tout pour éviter d'utiliser un mot-clé.

— MikeW

7

-1. Les utilisateurs de table (et pays, langues) peuvent être utilisés simultanément dans quelques applications.

— OZ_

129

L'association d'un nom de schéma ne supprimerait-elle pas toute confusion? AppName1.Users, AppName2.Users?

— Zo a

7

Je ne suis pas d'accord avec le préfixe de la table - cela devrait peut-être être un schéma? - mais je suis d'accord avec un "nom plus descriptif". Même quelque chose d'aussi simple que «AppUser» serait suffisant, sans entrer dans tout le débat sur l'espace de noms.

7

Cette réponse acceptée est plus un commentaire secondaire et ne répond pas à la question.

— Viliami

1826

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]

— Nestor
source

625

Je parie que si vous mettez une étiquette sur un tiroir à chaussettes, vous l'appellerez "Chaussettes".

— Chris Ward

73

Définitivement. Il est difficile d'obtenir une norme qui fonctionne pour tous et pour tout le monde, l'important est que cela fonctionne pour vous. Cela fonctionne pour moi, et ici j'ai expliqué pourquoi, mais encore une fois, c'est pour moi, et je le trouve très pratique.

— Nestor

451

Chris, la question la plus importante est la suivante: pourquoi suivriez-vous les conventions de dénomination de la base de données lorsque vous nommez un tiroir à chaussettes?

— Kyle Clegg

83

Cette réponse a besoin de plus d'éloges. Il discute d'un tas de raisons pratiques que j'applique à pourquoi je préfère les noms singuliers. Les discussions alternatives sur le langage approprié en référence aux ensembles sont juste philosophiques et obscurcissent le vrai point. Le singulier fonctionne mieux.

— Jason

298

J'ai un tiroir "chaussettes" à la maison, pas un tiroir "chaussettes". S'il s'agissait d'une base de données, je l'appellerais la table "Sock".

— jlembke

260

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.

— Brian Boatright
source

48

J'ai voté contre et je vais vous dire pourquoi, car je ne suis pas d'accord. L'ORM, par sa nature même, concerne la cartographie. Chaque outil ORM que j'ai jamais utilisé prend en charge la spécification du nom de table à utiliser pour une entité lorsqu'il est différent du nom de l'entité. Ceci est important parce que toute la raison pour laquelle nous mappons sur des bases de données relationnelles est pour que nous puissions facilement faire des requêtes et des rapports ad-hoc avec des formes différentes de notre modèle objet. Sinon, nous utiliserions tous des bases de données d'objets / documents maintenant.

— joshperry

25

L'ORM ne doit pas dicter les noms des objets auxquels ils sont mappés. Le point d'ORM est une abstraction de l'objet, accordant cette flexibilité.

— barrypicker

19

Dans mon monde, j'essaie d'utiliser des noms cohérents dans tout le projet pour éviter de perdre du temps à me demander si cette instance a un s à la fin ou non. Le fait qu'un ORM puisse renommer et être indépendant ne signifie pas que cela aide vos collègues développeurs.

— John Nicholas

2

Certains ORM (comme de nombreux outils de programmation) ont un comportement par défaut qui génère des implémentations sans configuration ... avec le point de vente de PRODUCTIVITY. Ainsi, la création d'une classe Employee, sans mappage explicite, générerait une table Employee par défaut

— user919426

1

@barrypicker. Les noms au pluriel ne semblent pas simplement stupides dans le code ORM. Les pluriels sont également mauvais en SQL, en particulier lorsqu'ils se réfèrent à un attribut unique. Qui n'a jamais écrit select user.id des utilisateurs? Ou peut-être ... des utilisateurs à gauche rejoindre sur thingy.user_id = user.id ...?

— Samuel Danielson

219

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.

— Ian Mackinnon
source

37

Probablement l'argument le plus logique sur ce sujet que j'ai jamais vu, et me fait plaisir d'avoir passé ce temps sur le latin. +1 à coup sûr.

52

Eh bien, j'ai clairement besoin de renforcer mon vocabulaire.

— TJ Biddle

19

+1 Vous voyez, ce sont les types de réponses dont Internet a le plus besoin. Des preuves impeccables utilisant un vocabulaire riche pour exécuter une logique parfaite.

— OCDev

8

J'en prendrai note la prochaine fois que je programmerai en latin. En attendant, les utilisateurs iront dans la table des utilisateurs et les clients dans la table des clients.

— Caltor

8

Convaincu - non influencé. Il est intéressant de voir qu'après tout ce temps, les choix populaires de "singulier" et "pluriel" sont tous les deux erronés!

— Stuart

126

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.

— Michael Haren
source

46

Lors de l'application de la théorie des ensembles aux tables, toute instance de l'ensemble est représentative de l'ensemble, donc Apple est un ensemble Apple, il est indépendant du nombre de pommes dans l'ensemble - c'est une Apple avec de nombreuses instances. Un «sac» de pommes ne devient pas un «sac» lorsqu'il contient de nombreuses pommes.

— ProfK

89

Et si vous avez un sac avec 5 pommes à l'intérieur? Vous appelez ça un sac de pomme? ou un sac de pommes?

— Christopher Mahan

26

Je pense que la théorie serait que l'ensemble s'appelle Pommes. Une pomme singulière est toujours "un ensemble de pommes" - quoique, un ensemble avec une seule instance. Plusieurs pommes sont également un "ensemble de pommes".

— Mark Brackett

26

@Christopher, si la raison d'être du sac est de contenir des pommes et seulement des pommes, alors c'est un "sac à pommes", qu'il contienne 1 pomme, 100 pommes ou pas de pommes.

— Ian Mackinnon

14

@ Ian: C'est parce qu'un tableau est générique et peut être comparé à un conteneur d'expédition (peut contenir presque tout, des caisses de pommes aux caisses de motos Harley Davidson). Vous dites: un conteneur de fret d'oranges, pas un conteneur de fret orange. Vous dites: un conteneur de fret de pièces automobiles, pas un conteneur de fret de pièces automobiles. Si vous avez créé une structure de données personnalisée destinée à contenir uniquement un type spécifique de données, telles que les noms des pommes, et que vous l'avez nommée "kungabogo", vous pourriez avoir un kungaboko aux pommes. Je sais ce que vous pensez, mais pensez d'abord à un sac de balles et comprenez la différence de sens.

— Christopher Mahan

79

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 .

— james
source

50

Dans cet exemple, oui, mais en sql pratique, il ne serait jamais écrit de cette façon. Vous auriez un alias de table donc ce serait plus commeSELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'

— Michael Haren

+1, (un an plus tard) Vous avez cité un exemple TERRIFIC sur le sens du singulier. Il s'agit en quelque sorte d'un débat religieux. J'ai été tourné au singulier il y a plusieurs années par un architecte de données de nombreuses années mon aîné et cela m'a paru juste (après avoir exigé beaucoup de conviction pour moi de basculer).

— Chris Adragna

24

Je pense que le sql sonne mieux au pluriel. Vous n'auriez pas de noms de table pour chaque colonne, pourquoi aimez-vous tellement taper. CHOISIR le nom, l'adresse des clients O Customers le nom> "def" Vous sélectionnez dans le groupe de clients où le nom est supérieur à def.

— Jamiegs

6

Que diriez-vous d'utiliser un alias / AS pour contourner ce problème? SELECT Customer.Name, Customer.Address FROM Customers AS Customer WHERE Customer.Name> "def"

— James Hughes

1

Le second sonne beaucoup mieux, des sons singuliers comme quelqu'un qui ne parle pas anglais.

— HLGEM

61

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.

— Adam Carr
source

3

J'aime particulièrement le commentaire de l'instruction SQL. L'utilisation du singulier ici ne semble pas intuitive pour le lecteur.

— hochl

2

Excellent point sur l'ERD. Je soupçonne que c'est pourquoi, pour quelqu'un qui voit le monde à travers les yeux DBA, la dénomination singulière a du sens. Je soupçonne qu'ils n'obtiennent pas, comme vous le faites remarquer, la différence entre une entité et une collection d'entre eux.

— William T. Mallard,

1

Une table n'est pas une collection d'enregistrements; un tableau est une définition de ce à quoi ressemble un enregistrement. C'est la déconnexion que semblent avoir tous les gens du pluriel / du singulier.

— remer riche

Je ne suis pas d'accord avec le commentaire de l'instruction SQL. Que faire si vous voulez rejoindre contre le Users.Id

— Hashtable

1

Un old_lady a plusieurs chats OU old_ladies ont des chats. Je pense que les DRE se lisent mieux au pluriel. Et table d'entités, les tables ont beaucoup d'entités donc encore une fois je pense que le pluriel sonne bien.

— user3121518

39

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.

— Paulo Freitas
source

7

qu'en est-il d'un mot se terminant par un «s»? Si vous avez un tableau appelé «News» (juste à titre d'exemple), comment appelleriez-vous la collection de news? Newss? Ou appelleriez-vous le tableau «Nouveau»?

— Anthony

18

J'appellerais la table NewsItem et une collection NewsItems.

— Ash Machine

5

Que faire si vous devez vérifier l'orthographe de tout le code sinon il ne sera pas compilé;)?

— Hamish Grubijan

2

L'ORM ne doit pas dicter les noms des objets auxquels ils sont mappés. Le point d'ORM est une abstraction de l'objet, accordant cette flexibilité.

— barrypicker

16

@HamishGrubijan puis arrêtez d'utiliser Word pour écrire votre code! ;)

— Valentino Vranken

37

À 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 .

— Gulzar Nazim
source

33

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.

— Jacob Lorensen
source

1

exactement. la principale chose que beaucoup de gens ne savent pas ici, c'est ce qu'ils nomment ... vous donnez un nom à une relation (un seul enregistrement dans le tableau), pas l'ensemble des enregistrements dans le tableau.

— Alexandre Martini

3

Je ne pourrais pas être plus en désaccord. 'Sélectionnez * parmi les utilisateurs dont le nom est comme' J% '' car je sélectionne tous les utilisateurs dont le nom commence par 'J'. Si votre argument est que vous voulez écrire '... où User.Name comme ...', utilisez simplement un alias. Même raison pour laquelle je dis "Donnez-moi une paire de toutes les chaussettes disponibles".

— Mark A. Donohoe

Si j'étais ce particulier, mon nom de table serait sock_pair

— Manuel Hernandez

@AlexandreMartini Exactement. Comme certaines personnes qui appellent un seul enregistrement dans le tableau "relation".

— Nuno André

31

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.

— Paulo Freitas
source

8

Je suis d'accord .. pourquoi l'incohérence entre le code et le stockage? Je ne nommerais jamais une collection d'objets utilisateur "Utilisateur" dans le code ... alors pourquoi devrais-je appeler une table comme ça? Cela n'a aucun sens. Quand je lis les arguments ci-dessus à ce sujet, ils se concentrent sur l'entité, pas sur le tableau ... il y a une distinction entre ce qui est dans le tableau et le tableau lui-même dans mon esprit.

— Jason

Comment gérez-vous un nom de table comme companieslorsque d'autres tables ont un champ de référence appelé company_id? Bien qu'il soit correctement orthographié, il semble incohérent pour ceux qui sont pointilleux sur les conventions de dénomination des tables.

— Jake Wilson

1

En se rappelant que le singulier de companiesest company, et que cet id est une référence à un élément singulier. Cela ne devrait pas nous déranger plus dans le code que cela ne nous dérange en anglais.

— David

22

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.

— Quelqu'un
source

Il n'est pas judicieux d'utiliser une telle convention dans le monde du modèle relationnel, en particulier lorsque vous décrivez la relation entre les objets, par exemple "Chaque équipe peut avoir un seul entraîneur principal et plusieurs entraîneurs secondaires", ce qui est décrit: Team-> MainCoach, Team - >> SecondaryCoach

— noonex

16

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.

— le chaos
source

À chacun le sien, je suppose. Une table de base de données relationnelle est par définition un en-tête (c'est-à-dire des métadonnées nommant les attributs) et un ensemble de tuples correspondant à l'en-tête. Vous pouvez vous concentrer sur les métadonnées, tandis que d'autres se concentrent sur les tuples. :-)

— Bill Karwin

Hé, User_Table est un nom que j'aime! :)

— Camilo Martin

3

L'ORM ne doit pas dicter les noms des objets auxquels ils sont mappés. Le point d'ORM est une abstraction de l'objet, accordant cette flexibilité.

— barrypicker

1

Je le regarde de cette façon .. si vous créez un tableau / liste / dictionnaire de quoi que ce soit dans le code, je parie que vous le nommez au pluriel de ce qu'il contient. Si vous utilisez un ORM pour résumer votre base de données, les tables sont représentées avec une sorte de collection, alors pourquoi les traiteriez-vous différemment? Utiliser des noms singuliers peut sembler bon, mais vous combattez toujours votre instinct qu'une table contient beaucoup de la même chose, tout comme une collection dans le code. Pourquoi l'incohérence?

— Jason

@ Jason: S'il vous plaît comparer la façon dont ces choses lisent comme suit: 1) $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something).

— chaos

16

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.

— Randy
source

9

N'est-ce pas aussi la convention en RoR? Nom pluriel pour les tables et Singular pour les classes ORM? Cela a beaucoup de sens pour moi. La table est appelée "voitures" car elle contient de nombreuses instances de "voiture" et la classe est appelée "voitures" car elle contiendra une instance de voiture !!

— Sap

@Sap Une correction mineure de la dernière partie de votre phrase - La classe "Car" est un DataType abstrait représentant une voiture réelle. Qu'il contienne une ou plusieurs instances dépend de la façon dont il est utilisé.

— asgs

avouons-le, le tableau carest une définition de la structure d'une seule voiture. Si vous regardez la structure de la table, elle crachera essentiellement "id int, chaîne de couleur, etc." en outre: dites-vous que vous avez une table car_vendor(ou pour votre version plurielle, ce serait cars_vendor) avec la clé étrangère cars_id?! quelle est cette merde stupide? ce n'est car_id pas la peine de me faire réfléchir. Le singulier est fortement préféré par moi

— Toskan

4

J'aime vraiment cette réponse! Laisse-moi expliquer. Si la collection est caret que vous voulez que tout carsoit, bluele résultat devrait être quelque chose comme tire, mirror, engine. Et puis cela devient confus parce que tous les résultats proviennent partsd'un car. Donc, le nom de la table devrait être carparts(ou car_parts, CarPartscomme vous voulez)

— arnoudhgz

Tout concepteur de base de données qui applique des noms de table singuliers déclare fondamentalement la guerre aux développeurs d'applications Ruby on Rails qui pourraient entrer en contact avec cette base de données à l'avenir. L'insistance stricte de Rail sur les mots singuliers pour les classes et les noms pluralisés pour les tables, permet de nombreux comportements puissants au sein de nombreux joyaux de l'écosystème de Ruby. Donc, même si vous pensez que le singulier sonne mieux, pour des raisons de compatibilité, vous devez vous en tenir au pluriel. J'imagine que cela vaut également pour de nombreux autres mappeurs relationnels d'objets.

— Kelsey Hannan

15

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é.

— Eugene Yokota
source

8

Nous, au pluriel, nommons la colonne 'id' comme vous le faites, ou 'singular_id'. Je crois que les tables doivent être plurielles (pensez-y comme des tableaux), mais les noms de colonnes doivent être singuliers (attributs d'un seul élément).

— mpen

plu_ral / PluRal pour les noms de table, singular_id / singularId pour les clés primaires.

— hochl

14

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.

— stephbu
source

On dirait une auto-flagellation rituelle. Y a-t-il déjà eu une telle saisie de nom?

— Kjetil

13

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.

— Andrew
source

1

Plus proche de mon point de vue, mais le mien est que le stockage de plusieurs utilisateurs dans la table est en fait accessoire, et que tout utilisateur singulier est représenté par la table, ou plutôt la relation qui est un ensemble de tuples représentant une entité utilisateur.

— ProfK

Je pense que j'ai tendance à être d'accord avec cela. La seule chose qui me déroute, c'est pourquoi les modèles devraient-ils être singuliers? Uniquement si le modèle ne concerne qu'un seul utilisateur. Si je questionnais la base de données pour obtenir tous les utilisateurs, aurais-je besoin d'accéder au modèle? Il n'est pas logique qu'une instance singulière récupère tous les enregistrements, par exemple: $ user-> get_all () // n'a pas de sens

— PM7Temp

12

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.

— Shane Delmore
source

1

Bon exemple d'un piège de préfixation de noms d'objets avec un qualificatif «type»!

— Kenny Evitt

12

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.

— Michel
source

Microsoft est ce qu'il est d'abord pour des raisons commerciales (et souvent pour des raisons non éthiques), des raisons logiques en dernier. Ma seule raison de les suivre serait qu'ils sont le gros gorille et tout le monde va dans ce sens. Quand j'ai le choix, je choisis l'autre voie.

— Bruce Patin

1

Il convient de noter que le information_schemafait partie de la norme ISO / IEC 9075-11, la norme SQL. Et oui, il utilise plusieurs noms de tables / vues.

— Paulo Freitas

10

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 ...?

— Richard
source

1

Microsoft est ce qu'il est d'abord pour des raisons commerciales (et souvent pour des raisons non éthiques), des raisons logiques en dernier. Ma seule raison de les suivre serait qu'ils sont le gros gorille et tout le monde va dans ce sens. Quand j'ai le choix, je choisis l'autre voie.

— Bruce Patin

Deux choses. Premièrement, vous n'utiliseriez normalement pas les noms de table et écririez «sélectionnez l'ID DE OrderHeaders WHERE Reference = 'ABC123' parce que vous 'Sélectionnez tous les ID de OrderHeaders où quelque chose est vrai' mais si vous deviez utiliser des noms de table à cause d'un rejoindre ou quoi que ce soit, vous utiliseriez un alias comme ça ... 'sélectionnez OrderHeader.ID DE OrderHeaders comme OrderHeader Oer OrderHeader.Reference =' ABC123 '

— Mark A. Donohoe

9

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 ---

— Borzio
source

9

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.

— Dave Markle
source

2

J'aime votre idée de «préfixe», mais je l'appellerais SystemUser.

— ProfK

9

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"

— jleviaguirre
source

8

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.

— Chris
source

18

Ignorant les horreurs de la notation hongroise. Jamais, jamais, jamais utiliser sp_ devant les procédures stockées car MS-SQL l'utilise pour les procédures stockées système et les traite comme spéciales. Étant donné que sp_ sont stockés dans la table principale, MS-SQL regarde toujours en premier, même si vous qualifiez l'emplacement.

— Will Dieterich,

8

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.

— helloworlder
source

À l'université on m'apprend le pluriel pour les tables, j'ai aussi un livre ici, DB management troisième édition des années 90, les tables sont singulières; tandis que j'ai également une copie mise à jour, 11e, singulier et quelques noms abrégés, tandis que la section XML utilise le pluriel. \ n Mais si vous vérifiez le contenu réel des sections SGBDR, il s'agit toujours du même texte, certaines images ayant subi un lifting. \ n La "liste de contrôle de la modélisation des données" n'indique rien au pluriel ou au singulier, juste que les entités ne doivent correspondre qu'à un seul objet, c'est probablement ce qu'elles essayaient d'imposer dans les livres.

— Marco

8

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.

— Bruce Patin
source

8

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.

— Just Some Guy
source

7

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)

— James Curran
source

11

Cette convention a fait partie de la théorie relationnelle longtemps, longtemps avant que l'ORM n'existe.

— ProfK

1

L'ORM ne doit pas dicter les noms des objets auxquels ils sont mappés. Le point d'ORM est une abstraction de l'objet, accordant cette flexibilité.

— barrypicker

7

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

— policier
source

6

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).

— jerseyboy
source