Table de Nommage Dilemme: Singulier vs Pluriel des Noms

Question

La Convention a que les noms de table doivent être au singulier de l'entité qu'ils stocker les attributs de.

Je n'aime pas tous les T-SQL qui nécessite des crochets autour des noms, mais j'ai renommé un Users tableau pour le singulier, jamais de condamnation pour ceux qui utilisent la table de parfois utiliser des crochets.

Mon impression est qu'il est plus correct de rester au singulier, mais mon instinct est aussi que les crochets indiquent les indésirables comme des noms de colonnes avec des espaces à l'etc.

Devrais-je rester ou doit-je aller?

Answer 1

J'ai eu la même question, et après avoir lu toutes les réponses ici, j'ai certainement rester avec le SINGULIER, raisons:

Raison 1 (Concept). Vous pouvez penser à un sac contenant des pommes comme "AppleBag", il n'a pas d'importance si contient 0 ou 1, ou un million de pommes, c'est toujours le même sac. Les Tables sont ce qu'ils sont, des conteneurs, le nom de la table doit décrire ce qu'il contient, pas de la quantité de données qu'il contient.

Raison 2. (Commodité). il est plus facile de sortir avec des noms singuliers, qu'avec le pluriel. Les objets peuvent avoir les pluriels irréguliers ou pas de pluriel en tout, mais aura toujours un singulier (avec quelques exceptions comme les Nouvelles).

• Client
• Afin
• L'utilisateur
• Statut
• News

Raison 3. (Esthétique et de l'Ordre). Spécialement dans le maître-détail des scénarios, il se lit mieux, correspond mieux par leur nom, et ont plus de logique d'ordre (Maître d'abord, Détail de la seconde):

• 1.Afin
• 2.OrderDetail

Par rapport à:

• 1.OrderDetails
• 2.Les commandes

Raison 4 (Simplicité). Mettons tous ensemble, Noms de Table, les Clés Primaires, les Relations, les Classes d'Entité... est préférable d'être conscient d'un seul nom (singulier) au lieu de deux (singulier de classe, pluriel de table, singulier champ, 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 traitez avec le "Client", vous pouvez être sûr que vous utilisez le même mot pour l'ensemble de votre base de données interaction besoins.

Raison 5. (La mondialisation). Le monde devient plus petit, vous pouvez avoir une équipe de nationalités différentes, pas tout le monde a l'anglais comme langue maternelle. Serait plus facile pour un non-natif de la langue anglaise programmeur de penser de "Référentiel" que de "Référentiels", ou de les éviter type "Statuts" au lieu de "Statut". Avoir des noms singuliers peuvent conduire à réduire les erreurs causées par les fautes de frappe, d'économiser du temps d'éviter les dépenses de secondes supplémentaires de penser "est-il de l'Enfant ou des Enfants?", d'où l'amélioration de la productivité.

Raison 6. (Pourquoi pas?). Il peut même vous sauver de l'écriture du temps, économiser de l'espace disque, et même faire votre clavier d'ordinateur dure plus!

• 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, un supplément de 3 clavier hits :)

Et enfin, vous pouvez donner un nom à ceux gâcher avec des noms réservés comme:

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

Ou utiliser le tristement célèbre carré de crochets [Utilisateur]

Answer 2

Si vous utilisez le Mapping Objet-Relationnel outils ou seront à l'avenir je suggère Singulier.

Certains outils comme LLBLGen peut corriger automatiquement le pluriel des noms comme les Utilisateurs de l'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 de l'Utilisateur.Nom de la place des Utilisateurs.Nom ou pour le pire de certains de mes bases de données de tables de nommage tblUsers.strName qui est juste à confusion dans le code.

Ma nouvelle règle de base est de juger de la façon dont il va chercher une fois qu'il a été converti en un objet.

un tableau que j'ai trouvé qui ne correspond pas à la nouvelle appellation que j'utilise est UsersInRoles. Mais il y aura toujours ces quelques exceptions, et même dans ce cas, il semble bien que UsersInRoles.Nom d'utilisateur.

Answer 3

D'autres ont donné assez de bonnes réponses dans la mesure où les "normes" d'y aller, mais je voulais juste ajouter ceci... Est-il possible que "Utilisateur" (ou les "Utilisateurs") n'est en fait pas une description complète des données contenues dans la table? Non pas que vous devriez aller trop loin avec les noms de table et de spécificité, mais peut-être quelque chose comme "Widget_Users" ("Widget" est le nom de votre application ou site web) serait plus approprié.

Answer 4

Dans son livre "SQL Style de Programmation," Joe Celko suggère qu'une collection (par exemple un tableau) devrait être nommé au pluriel, tandis qu'un scalaire de l'élément de données (par exemple, une colonne) doit être nommé dans le singulier.

Il cite ISO 11179-4 comme un standard pour les métadonnées de nommage, qui prend en charge cette directive.

Answer 5

Ce que la convention exige que les tables ont des noms singuliers? J'ai toujours pensé que c'était le pluriel des noms.

Un utilisateur est ajouté à la table des Utilisateurs.

Ce site s'engage à:
http://vyaskn.tripod.com/object_naming.htm#Tables

Ce site n'est pas d'accord (mais je suis en désaccord avec elle):
http://justinsomnia.org/writings/naming_conventions.html

---

Comme d'autres l'ont mentionné: ce sont des lignes directrices. Choisissez une convention qui fonctionne pour vous et votre entreprise/projet et de s'y tenir. La commutation entre le singulier et le pluriel ou parfois abréger les mots et parfois pas beaucoup plus aggravante.