Plural vs Singular Table Name
Comment dois-je nommer mes tables lors de la création d'une nouvelle base de données?
Singulier: Client ou Pluriel: Clients?
Dépend de vous. Soyez tout de même cohérent.
Personnellement Je préfère le singulier en fonction de ce que chaque * ligne "stocke: commande, produit, utilisateur, article, etc.
Cela correspond à ma modélisation (via la modélisation de rôle d'objet) où j'utilise des entités/types singuliers.
Éditer:
Une des raisons est que le pluriel échoue lorsque vous avez des tables de liens:Orders, Products donnerait OrderProducts ou OrdersProducts. Aucun des deux ne semble correct
Ou des tableaux d'historique (bien sûr, vous pouvez utiliser des schémas pour cela):Orders -> OrdersHistory ou (non!) OrdersHistories? Order-> OrderHistory ne serait-il pas mieux?
En ce qui concerne les noms de table au singulier et au pluriel, le sujet semble controversé, mais il ne devrait pas l'être.
Alors qu'une table est une collection de plusieurs enregistrements, une table est nommée d'après la définition du seul type d'enregistrement qu'elle contient. Si une table était autorisée à porter un nom différent de celui du type d'enregistrement qu'elle contient, vous pourriez donner à la table un nom pluriel, de sorte que vous puissiez par exemple avoir une table Employés contenant plusieurs enregistrements Employé. Mais le concepteur de SQL n'a pas fourni de noms distincts pour les tables et les types d'enregistrement.
Les choses fonctionnent plus logiquement pour les programmes orientés objet qui utilisent les données, si le nom d'un type d'enregistrement (et par extension le nom de la table) est conservé au singulier, car il correspondra au nom de la classe que vous utiliseriez pour décrire un enregistrement .
Si vous souhaitez ensuite identifier une collection dans le programme, vous pouvez utiliser un pluriel, ou mieux, utiliser un modificateur approprié, tel que EmployeeList ou EmployeeArray.
Il existe également un problème avec les pluriels irréguliers pour la génération automatique de code et les programmeurs qui ont des antécédents linguistiques différents ou des idées sur la formation de pluriels dans un programme.
La langue anglaise n'est pas un bon langage de programmation, et essayer de rendre les instructions de base de données et de programme conformes à l'anglais car il semble préférable de lire l'une de ces instructions est une erreur.
Tout comme @ gbn réponse je pense que c'est plus une question de préférences et comme lui, je recommande que tout choix que vous fassiez, l'applique partout (dans cette BD au moins). La cohérence en vaut la peine.
Ma préférence, cependant, est qu'un pluriel sonne mieux dans les instructions SELECT:
SELECT Id, Name, Status
FROM Persons
WHERE Status <> 5 --5 meaning deleted
Je veux dire dans ce cas, au moins, il y a plusieurs personnes dans la table et plusieurs d'entre elles sont retournées au client.
"commande" est un mot réservé. "commandes" n'est pas
"utilisateur" est un mot réservé. "utilisateurs" n'est pas
"session" est un mot réservé. "sessions" n'est pas
"résultat" est un mot réservé. "résultats" n'est pas
"relative" est un mot réservé. "parents" n'est pas
...
Ceux-ci semblent être des mots courants qui pourraient aller dans la base de données du secteur d'activité. Les mots pluriels semblent moins courants comme mots clés que les mots singuliers. Par conséquent, il pourrait être avantageux d'utiliser plusieurs noms de table afin d'éviter tout conflit avec les mots clés SQL.
Je crois que la table SQL devrait avoir plusieurs noms. Il se lit simplement beaucoup mieux.
Un tableau des enregistrements de livres devrait être appelé livres. L'ORM doit utiliser la même convention. L'objet Books est une collection et préside tous les enregistrements de la table Books. Un objet Livre préside à un seul enregistrement.
Cela rend le codage plus naturel.
select name, publication_date from books where publication_date > '2000-01-01';
books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
print book.name
Après avoir travaillé avec la programmation pendant quelques années, j'ai conclu que la pluralisation est une complication inutile. Mon opinion est que selon la philosophie KISS un programmeur devrait s'efforcer de trouver la solution la plus paresseuse et la plus facile à tous les problèmes pour des raisons de temps et d'efficacité. Ainsi, le singulier vous donne moins de travail nécessaire dans tous les scénarios.
Nous considérons les choses sous différents angles, et je pense que les deux camps sont identifiés par:
Singulier ("utilisateur")
La personne qui établit une corrélation entre le nom de la table et le fait qu'il représente un conteneur, qui peut contenir plusieurs lignes.
Le "conteneur utilisateur" peut donc contenir plusieurs lignes.
Pluriel ("utilisateurs")
La personne qui ne fait pas la corrélation entre le nom de la table et le fait qu'il représente un conteneur. Bien sûr, ils savent que c'est un conteneur, mais ce n'est pas là dans le nom.
par exemple.
Un "carton d'oeufs" peut contenir plusieurs œufs, mais cela est évident car la référence du récipient est dans le nom, offrant un potentiel pour plusieurs œufs. Cependant, avec le nom de table singulier "utilisateur", la référence de conteneur n'est pas là dans le nom. Par exemple, "user_container" serait probablement acceptable pour les personnes qui préfèrent les noms pluriels.
Je pense que cela est également dû à des années de pratique courante au pluriel et dans la plupart des supports pédagogiques en ligne.
Cela dit, je pense que, techniquement parlant, le singulier est plus précis étant donné que nous nommons un seul conteneur, et que les conteneurs peuvent contenir plusieurs (ou une seule) lignes.
Cela semble mal aux gens car ils lient mentalement le nom de la table au contenu (plusieurs lignes nécessitent un nom pluriel) plutôt que de lier mentalement le conteneur nommé au contenu (un conteneur permet plusieurs).
Comme toujours, il n'y a souvent pas de bien et de mal, et il s'agit davantage de ce qui convient au scénario et, surtout, d'être cohérent avec ce que vous choisissez.
Si vous faites le projet uniquement et qu'il n'y a aucune raison réelle d'aller dans les deux sens, faites ce que vous jugez le mieux, ou tout simplement de préférence. Appliquez la même chose dans une équipe de développement et venez à une décision unanime.
C'est une chose très personnelle. J'utilise la forme singulière depuis 30 ans. Mais je peux voir pourquoi les gens aiment les pluriels. Les livres - auteurs sont intéressants car je pense que les auteurs de livres n'ont pas tort. Un livre peut avoir un ou plusieurs auteurs. Et les auteurs peuvent avoir écrit un ou plusieurs livres (par exemple co-écrit). Cela dépend également de la façon dont vous gérez les livres écrits par plusieurs auteurs. Je suis d'accord avec d'autres réponses; choisissez-en un et soyez cohérent. En ce qui concerne les problèmes de mots réservés. Je pense qu'il n'est pas difficile de trouver des noms de contournement. utilisateur -> app_user, session -> app_session, order -> customer_order