Conventions de dénomination des bases de données, des tables et des colonnes ?[fermé]

https://stackoverflow.com/questions/7662

08-06-2019
|

Question

Chaque fois que je conçois une base de données, je me demande toujours s'il existe une meilleure façon de nommer un élément dans ma base de données.Très souvent, je me pose les questions suivantes :

Les noms de tables doivent-ils être au pluriel ?
Les noms de colonnes doivent-ils être au singulier ?
Dois-je préfixer des tableaux ou des colonnes ?
Dois-je utiliser n'importe quelle casse pour nommer les éléments ?

Existe-t-il des directives recommandées pour nommer les éléments dans une base de données ?

La solution

Je recommande de consulter les exemples de bases de données SQL Server de Microsoft :https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

L'exemple AdventureWorks utilise une convention de dénomination très claire et cohérente qui utilise des noms de schéma pour l'organisation des objets de base de données.

Noms singuliers pour les tables
Noms singuliers pour les colonnes
Nom du schéma pour le préfixe des tables (par exemple :NomSchéma.NomTable)
Boîtier Pascal (aliasboîtier supérieur camel)

Autres conseils

Réponse tardive ici, mais en bref :

Mon préférence est au pluriel
Oui
les tables:*Habituellement*, il est préférable de ne pas utiliser de préfixes. Colonnes:Non.
Tableaux et colonnes :PascalCase.

Élaboration:

(1) Ce que vous devez faire. Il y a très peu de choses que vous doit faites d'une certaine manière, à chaque fois, mais il y en a quelques-unes.

Nommez votre clés primaires en utilisant le format "[singularOfTableName]ID".Autrement dit, si le nom de votre table est Client ou Clients, la clé primaire doit être N ° de client.
Plus loin, clés étrangères doit être nommé de manière cohérente dans différents tableaux.Il devrait être légal de tabasser quelqu'un qui ne le fait pas.Je dirais que même si les contraintes de clé étrangère définies sont souvent une dénomination de clé étrangère importante et cohérente est toujours important
Votre base de données doit avoir conventions internes.Même si dans les sections suivantes, vous me verrez très flexible, dans un nom de base de données doit être très cohérent.Si votre table pour les clients est appelée Clients ou Client est moins important que de le faire de la même manière dans la même base de données.Et vous pouvez lancer une pièce pour déterminer comment utiliser les traits de soulignement, mais alors vous il faut continuer à les utiliser de la même manière.Si vous ne le faites pas, vous êtes une mauvaise personne qui devrait avoir une faible estime de soi.

(2) Ce que vous devriez probablement faire.

Champs représentant le même type de données sur différentes tables devrait porter le même nom.Ne pas avoir Zip sur une table et ZipCode sur une autre.
Pour séparer les mots dans les noms de vos tables ou colonnes, utilisez PascalCasing.Utiliser camelCasing ne serait pas intrinsèquement problématique, mais ce n'est pas la convention et cela aurait l'air drôle.Je parlerai des traits de soulignement dans un instant.(Vous ne pouvez pas utiliser ALLCAPS comme autrefois.OBNOXIOUSTABLE.ANNOYING_COLUMN était correct dans DB2 il y a 20 ans, mais plus maintenant.)
Ne raccourcissez pas ou n’abrégez pas artificiellement les mots.Il vaut mieux qu’un nom soit long et clair plutôt que court et déroutant.Les noms ultra-courts sont un vestige d’époques plus sombres et plus sauvages.Cus_AddRef.Qu'est-ce que c'est que ça ?Référence du destinataire dépositaire ?Remboursement supplémentaire du client ?Référence d'adresse personnalisée ?

(3) Ce que vous devriez considérer.

Je pense vraiment que vous devriez avoir des noms au pluriel pour les tables ;certains pensent singulier.Lisez les arguments ailleurs.Les noms de colonnes doivent cependant être au singulier.Même si vous utilisez des noms de table au pluriel, les tableaux qui représentent des combinaisons d'autres tableaux peuvent être au singulier.Par exemple, si vous avez un Promotions Et un Articles table, une table représentant un article faisant partie d'une promotion pourrait être Promotions_Items, mais elle pourrait aussi légitimement être Promotion_Items je pense (reflétant la relation un-à-plusieurs).
Utilisez les traits de soulignement de manière cohérente et dans un but particulier.Seuls les noms généraux des tables doivent être suffisamment clairs avec PascalCasing ;vous n'avez pas besoin de traits de soulignement pour séparer les mots.Enregistrez les traits de soulignement soit (a) pour indiquer une table associative, soit (b) pour le préfixe, ce que j'aborderai dans la puce suivante.
Le préfixe n’est ni bon ni mauvais.Il généralement n'est pas le meilleur.Dans votre ou vos deux premières bases de données, je ne suggérerais pas d'utiliser des préfixes pour le regroupement thématique général des tables.Les tableaux finissent par ne pas s'adapter facilement à vos catégories, et cela peut en fait les rendre Plus fort pour trouver des tables.Avec l’expérience, vous pouvez planifier et appliquer un système de préfixation qui fait plus de bien que de mal.J'ai travaillé une fois dans une base de données où les tables de données commençaient par à table, configurez les tables avec ctbl, vues avec voir, processus sp, et udf fn, et quelques autres ;cela a été appliqué méticuleusement et systématiquement, donc tout s’est bien passé.La seule fois où vous avez BESOIN de préfixes, c'est lorsque vous avez des solutions vraiment distinctes qui, pour une raison quelconque, résident dans la même base de données ;les préfixer peut être très utile pour regrouper les tableaux.Le préfixage est également acceptable dans des situations particulières, comme pour les tables temporaires que vous souhaitez mettre en valeur.
Très rarement (si jamais) voudriez-vous préfixer les colonnes.

Ok, puisque nous pesons notre avis :

Je crois que les noms de tables doivent être au pluriel.Les tables sont une collection (une table) d'entités.Chaque ligne représente une seule entité et le tableau représente la collection.J'appellerais donc une table d'entités Personne Personnes (ou Personnes, selon votre fantaisie).

Pour ceux qui aiment voir des « noms d’entités » singuliers dans les requêtes, c’est pour cela que j’utiliserais les alias de table :

SELECT person.Name
FROM People person

Un peu comme "de personne en personne, sélectionnez personne.Nom" de LINQ.

Quant aux 2, 3 et 4, je suis d'accord avec @Lars.

Je travaille dans une équipe de support de bases de données avec trois administrateurs de base de données et nos options envisagées sont :

N’importe quelle norme de dénomination vaut mieux que pas de norme.
Il n’existe pas de « véritable » norme, nous avons tous nos préférences
S’il existe déjà une norme, utilisez-la.Ne créez pas une autre norme et ne brouillez pas les normes existantes.

Nous utilisons des noms singuliers pour les tables.Les tableaux ont tendance à être préfixés par le nom du système (ou son acronyme).Ceci est utile si le système est complexe, car vous pouvez modifier le préfixe pour regrouper les tables de manière logique (c.-à-d.reg_customer, reg_booking et regadmin_limits).

Pour les champs, nous nous attendons à ce que les noms de champs incluent le préfixe/acryonme de la table (c'est-à-direcust_address1) et nous préférons également l'utilisation d'un ensemble standard de suffixes ( _id pour le PK, _cd pour "code", _nm pour "name", _nb pour "number", _dt pour "Date").

Le nom du champ Clé étrangère doit être le même que celui du champ Clé primaire.

c'est à dire.

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Lors du développement d'un nouveau projet, je vous recommande d'écrire tous les noms, préfixes et acronymes d'entités préférés et de remettre ce document à vos développeurs.Ensuite, lorsqu'ils décident de créer une nouvelle table, ils peuvent se référer au document plutôt que de « deviner » comment la table et les champs doivent être appelés.

Non.Une table doit porter le nom de l'entité qu'elle représente.Personne, et non personnes, c'est ainsi que vous feriez référence à la personne que représente l'un des enregistrements.
Encore une fois, même chose.La colonne FirstName ne devrait vraiment pas s'appeler FirstNames.Tout dépend de ce que vous voulez représenter avec la colonne.
NON.
Oui.Affaire-le pour plus de clarté.Si vous avez besoin de colonnes telles que « Prénom », la casse facilitera la lecture.

D'accord.C'est mon 0,02 $

Je suis également en faveur d'une convention de dénomination de style ISO/IEC 11179, notant qu'il s'agit de lignes directrices plutôt que prescriptives.

Voir Nom de l'élément de données sur Wikipédia:

"Les tables sont des collections d'entités et suivent les directives de dénomination des collections.Idéalement, un nom collectif est utilisé :par exemple, Personnel.Le pluriel est également correct :Employés.Les noms incorrects incluent :Employee, tblEmployee et EmployeeTable."

Comme toujours, il existe des exceptions aux règles, par ex.un tableau qui a toujours exactement une ligne peut être préférable avec un nom singulier, par ex.une table de configuration.Et la cohérence est de la plus haute importance :vérifiez si votre magasin a une convention et, si oui, suivez-la ;si vous ne l'aimez pas, faites une analyse de rentabilisation pour la modifier plutôt que d'être le seul garde forestier.

notre préférence :

Les noms de tables doivent-ils être au pluriel ?
Jamais.Les arguments en faveur d'une collection ont du sens, mais on ne sait jamais ce que la table va contenir (0,1 ou plusieurs éléments).Les règles plurielles compliquent inutilement la dénomination.1 maison, 2 maisons, souris contre souris, personne contre personnes, et nous n'avons même pas examiné d'autres langues.

Update person set property = 'value' agit sur chaque personne du tableau.
Select * from person where person.name = 'Greg' renvoie une collection/ensemble de lignes de lignes de personnes.
Les noms de colonnes doivent-ils être au singulier ?
Habituellement, oui, sauf lorsque vous enfreignez les règles de normalisation.
Dois-je préfixer des tableaux ou des colonnes ?
Principalement une préférence de plate-forme.Nous préférons préfixer les colonnes avec le nom de la table.Nous ne préfixons pas les tables, mais nous préfixons les vues (v_) et les procédures stockées (sp_ ou f_ (fonction)).Cela aide les personnes qui souhaitent essayer de mettre à jour v_person.age qui est en fait un champ calculé dans une vue (qui ne peut pas être mis à jour de toute façon).

C'est également un excellent moyen d'éviter les collisions de mots clés (les pauses delivery.from, mais pas delivery_from).

Cela rend le code plus verbeux, mais facilite souvent la lisibilité.

bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
...est très lisible et explicite.Cela peut cependant devenir incontrôlable :

customer.customer_customer_type_id

indique une relation entre le client et la table customer_type, indique la clé primaire sur la table customer_type (customer_type_id) et si jamais vous voyez 'customer_customer_type_id' lors du débogage d'une requête, vous savez instantanément d'où elle vient (table client).

ou lorsque vous avez une relation M-M entre customer_type et customer_category (seuls certains types sont disponibles pour certaines catégories)

customer_category_customer_type_id

...est un peu (!) du côté long.
Dois-je utiliser n'importe quelle casse pour nommer les éléments ?Oui - minuscules :), avec traits de soulignement.Ceux-ci sont très lisibles et multiplateformes.Avec 3 ci-dessus, cela a également du sens.

Il s’agit cependant pour la plupart de préférences.- Tant que vous êtes cohérent, cela devrait être prévisible pour quiconque doit le lire.

J'entends constamment l'argument selon lequel le fait qu'un tableau soit pluralisé ou non est une question de goût personnel et qu'il n'existe pas de meilleure pratique.Je ne crois pas que ce soit vrai, surtout en tant que programmeur par opposition à DBA.Pour autant que je sache, il n'y a aucune raison légitime de mettre au pluriel un nom de table autre que "Cela a du sens pour moi parce que c'est une collection d'objets", alors qu'il y a des gains légitimes dans le code en ayant des noms de table singuliers.Par exemple:

Cela évite les bugs et les erreurs causées par les ambiguïtés plurielles.Les programmeurs ne sont pas vraiment connus pour leur expertise en orthographe, et la mise au pluriel de certains mots prête à confusion.Par exemple, le mot au pluriel se termine-t-il par « es » ou simplement par « s » ?Est-ce des personnes ou des personnes ?Lorsque vous travaillez sur un projet avec de grandes équipes, cela peut devenir problématique.Par exemple, un cas où un membre de l'équipe utilise la méthode incorrecte pour pluraliser un tableau qu'il crée.Au moment où j'interagis avec cette table, elle est utilisée partout dans du code auquel je n'ai pas accès ou qui prendrait trop de temps à corriger.Le résultat est que je dois me rappeler de mal épeler le tableau à chaque fois que je l’utilise.Il m'est arrivé quelque chose de très similaire.Plus vous pourrez permettre à chaque membre de l'équipe d'utiliser de manière cohérente et facile les noms de table exacts et corrects sans erreurs ni devoir rechercher les noms de table à tout moment, mieux ce sera.La version singulière est beaucoup plus facile à gérer dans un environnement d'équipe.
Si vous utilisez la version singulière d'un nom de table ET préfixez la clé primaire avec le nom de la table, vous avez désormais l'avantage de déterminer facilement un nom de table à partir d'une clé primaire ou vice versa via le code seul.Vous pouvez recevoir une variable contenant un nom de table, concaténer "Id" à la fin et vous disposez désormais de la clé primaire de la table via le code, sans avoir à effectuer une requête supplémentaire.Ou vous pouvez couper "Id" à la fin d'une clé primaire pour déterminer un nom de table via le code.Si vous utilisez "id" sans nom de table pour la clé primaire, vous ne pouvez pas, via le code, déterminer le nom de la table à partir de la clé primaire.De plus, la plupart des personnes qui mettent au pluriel les noms de table et préfixent les colonnes PK avec le nom de la table utilisent la version singulière du nom de la table dans le PK (par exemple statuses et statusId), ce qui rend cela impossible du tout.
Si vous créez des noms de table au singulier, vous pouvez les faire correspondre aux noms de classe qu'ils représentent.Encore une fois, cela peut simplifier le code et vous permettre de faire des choses vraiment intéressantes, comme instancier une classe en n'ayant rien d'autre que le nom de la table.Cela rend également votre code plus cohérent, ce qui conduit à...
Si vous donnez un nom de table au singulier, votre schéma de dénomination sera cohérent, organisé et facile à gérer dans chaque emplacement.Vous savez que dans chaque instance de votre code, que ce soit dans un nom de colonne, comme nom de classe ou comme nom de table, c'est exactement le même nom.Cela vous permet d'effectuer des recherches globales pour voir partout où les données sont utilisées.Lorsque vous mettez au pluriel un nom de table, il y aura des cas où vous utiliserez la version singulière de ce nom de table (la classe dans laquelle elle se transforme, dans la clé primaire).Il est tout simplement logique de ne pas avoir certaines instances où vos données sont appelées au pluriel et certaines instances au singulier.

Pour résumer, si vous mettez au pluriel les noms de vos tables, vous perdez toutes sortes d'avantages en rendant votre code plus intelligent et plus facile à gérer.Il peut même y avoir des cas où vous devrez disposer de tables/tableaux de recherche pour convertir les noms de vos tables en noms d'objets ou de codes locaux que vous auriez pu éviter.Les noms de table singuliers, même s'ils semblent peut-être un peu bizarres au début, offrent des avantages significatifs par rapport aux noms pluriels et je pense qu'ils constituent une bonne pratique.

Jetez un œil à la norme ISO 11179-5 :Principes de dénomination et d'identification Vous pouvez l'obtenir ici: http://metadata-standards.org/11179/#11179-5

J'en avais blogué il y a quelques temps ici : Conventions de dénomination ISO-11179

Je sais qu'il est tard dans le jeu et que la question a déjà reçu une très bonne réponse, mais je souhaite donner mon avis sur le point 3 concernant le préfixe des noms de colonnes.

Toutes les colonnes doivent être nommées avec un préfixe unique à la table dans laquelle elles sont définies.

Par exemple.Étant donné les tables "client" et "adresse", utilisons respectivement les préfixes "cust" et "addr"."client" aurait "cust_id", "cust_name", etc.dedans."address" aurait "addr_id", "addr_cust_id" (FK retour au client), "addr_street", etc.dedans.

Lorsqu’on m’a présenté cette norme pour la première fois, j’étais absolument contre ;Je détestais l'idée.Je ne supportais pas l'idée de toute cette saisie supplémentaire et de cette redondance.Maintenant, j'ai suffisamment d'expérience pour ne jamais y revenir.

Le résultat de cette opération est que toutes les colonnes de votre schéma de base de données sont uniques.Il y a un avantage majeur à cela, qui l'emporte sur tous les arguments contre (à mon avis, bien sûr) :

Vous pouvez effectuer une recherche dans l’intégralité de votre base de code et trouver de manière fiable chaque ligne de code touchant une colonne particulière.

L’avantage du n°1 est incroyablement énorme.Je peux rendre obsolète une colonne et savoir exactement quels fichiers doivent être mis à jour avant que la colonne puisse être supprimée du schéma en toute sécurité.Je peux changer la signification d'une colonne et savoir exactement quel code doit être refactorisé.Ou je peux simplement savoir si les données d'une colonne sont même utilisées dans une partie particulière du système.Je ne peux pas compter le nombre de fois où un projet potentiellement énorme a été transformé en un projet simple, ni le nombre d'heures que nous avons économisées en travail de développement.

Un autre avantage, relativement mineur, est que vous ne devez utiliser des alias de table que lorsque vous effectuez une auto-jointure :

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Mes opinions à ce sujet sont les suivantes :

1) Non, les noms de tables doivent être au singulier.

Bien que la simple sélection (select * from Orders) cela a moins de sens pour l'équivalent OO (Orders x = new Orders).

Une table dans une base de données est en réalité l'ensemble de cette entité, cela a plus de sens une fois que vous utilisez la logique d'ensemble :

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Cette dernière ligne, la logique réelle de la jointure, semble déroutante avec les noms de tables pluriels.

Je ne suis pas sûr de toujours utiliser un alias (comme le suggère Matt) pour clarifier cela.

2) Ils doivent être singuliers car ils ne détiennent qu’une seule propriété

3) Jamais, si le nom de la colonne est ambigu (comme ci-dessus où ils ont tous deux une colonne appelée [Clé]), le nom de la table (ou son alias) peut assez bien les distinguer.Vous souhaitez que les requêtes soient simples et rapides à saisir : les préfixes ajoutent une complexité inutile.

4) Quoi que vous vouliez, je suggère CapitalCase

Je ne pense pas qu'il existe un ensemble de lignes directrices absolues sur aucun de ces éléments.

Tant que tout ce que vous choisissez est cohérent dans l'ensemble de l'application ou de la base de données, je ne pense pas que cela ait vraiment d'importance.

À mon avis:

Les noms de tables doivent être au pluriel.
Les noms de colonnes doivent être au singulier.
Non.
Soit CamelCase (mon préféré), soit underscore_separated pour les noms de table et les noms de colonnes.

Cependant, comme cela a été mentionné, n’importe quelle convention vaut mieux que pas de convention.Quelle que soit la manière dont vous choisissez de le faire, documentez-le afin que les futures modifications suivent les mêmes conventions.

Gardez définitivement les noms de table au singulier, personne et non personnes
1. Pareil ici
2. Non.J'ai vu des préfixes terribles, allant jusqu'à indiquer qu'il s'agissait d'une table (tbl_) ou d'une procédure de magasin utilisateur (usp_).Ceci suivi du nom de la base de données...Ne le fais pas !
3. Oui.J'ai tendance à PascalCase tous mes noms de table

Je pense que la meilleure réponse à chacune de ces questions serait donnée par vous et votre équipe.Il est bien plus important d'avoir une convention de dénomination que de savoir exactement quelle est la convention de dénomination.

Comme il n'y a pas de bonne réponse à cette question, vous devriez prendre un peu de temps (mais pas trop) et choisir vos propres conventions et - voici la partie importante - tenez-vous-y.

Bien sûr, il est bon de rechercher des informations sur les normes à ce sujet, c'est ce que vous demandez, mais ne vous inquiétez pas du nombre de réponses différentes que vous pourriez obtenir :choisissez celui qui vous convient le mieux.

Au cas où, voici mes réponses :

Oui.Une table est un groupe de enregistrements, enseignants ou acteurs, donc...pluriel.
Oui.
Je ne les utilise pas.
La base de données que j'utilise le plus souvent - Firebird - garde tout en majuscules, donc cela n'a pas d'importance.Quoi qu'il en soit, lorsque je programme, j'écris les noms de manière à ce qu'ils soient plus faciles à lire, comme année de sortie.

Les conventions de dénomination permettent à l'équipe de développement de concevoir la découvrabilité et la maintenabilité au cœur du projet.

Une bonne convention de dénomination prend du temps à évoluer, mais une fois en place, elle permet à l’équipe d’avancer avec un langage commun.Une bonne convention de dénomination se développe de manière organique avec le projet.Une bonne convention de dénomination s'adapte facilement aux changements au cours de la phase la plus longue et la plus importante du cycle de vie du logiciel : la gestion des services en production.

Voici mes réponses :

Oui, les noms de tables doivent être au pluriel lorsqu'ils font référence à un ensemble de métiers, titres, ou contreparties Par exemple.
Oui.
Oui.Les tables SQL portent le préfixe tb_, les vues portent le préfixe vw_, les procédures stockées portent le préfixe usp_ et les déclencheurs portent le préfixe tg_ suivi du nom de la base de données.
Le nom de la colonne doit être en minuscules, séparé par un trait de soulignement.

Nommer est une tâche difficile, mais dans chaque organisation, il y a quelqu'un qui peut nommer les choses et dans chaque équipe logicielle, il devrait y avoir quelqu'un qui assume la responsabilité des normes de dénomination et veille à ce que les problèmes de dénomination tels que sec_id, valeur_sec et id_sécurité être résolus tôt avant d'être intégrés au projet.

Alors, quels sont les principes de base d’une bonne convention et de bons standards de dénomination :-

Utilisez la langue de votre client et votre domaine de solution
Soyez descriptif
Être cohérent
Lever l’ambiguïté, réfléchir et refactoriser
N'utilisez pas les abréviations à moins qu'ils ne soient clairs pour tout le monde
N'utilisez pas les mots clés réservés SQL comme noms de colonne

Voici un lien qui propose quelques choix.Je cherchais une spécification simple que je pourrais suivre plutôt que de devoir m'appuyer sur une spécification partiellement définie.

http://justinsomnia.org/writings/naming_conventions.html

Les noms de table doivent toujours être au singulier, car ils représentent un ensemble d'objets.Comme vous dites troupeau pour désigner un groupe de moutons, ou troupeau désigne un groupe d'oiseaux.Pas besoin de pluriel.Lorsqu'un nom de table est composé de deux noms et que la convention de dénomination est au pluriel, il devient difficile de savoir si le nom au pluriel doit être le premier mot, le deuxième mot ou les deux.C'est la logique – Objet.instance, pas objets.instance.Ou TableName.column, pas TableNames.column(s).Microsoft SQL n'est pas sensible à la casse, il est plus facile de lire les noms de table, si des lettres majuscules sont utilisées, pour séparer les noms de table ou de colonne lorsqu'elles sont composées de deux noms ou plus.

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Nom de la table: Il doit être singulier, car il s'agit d'une entité singulière représentant un objet du monde réel et non des objets, qui sont singuliers.

Nom de colonne: Il ne doit être singulier qu'alors il indique qu'il détiendra une valeur atomique et confirmera la théorie de la normalisation.Toutefois, s'il existe n nombres de propriétés du même type, elles doivent alors être suffixées par 1, 2, ..., n, etc.

Préfixe des tables/colonnes :C'est un vaste sujet, nous en parlerons plus tard.

Enveloppe:Ce devrait être l'affaire Camel

Mon ami, Patrick Karcher, je vous demande de ne rien écrire qui puisse être offensant pour quelqu'un, comme vous l'avez écrit : « De plus, les clés étrangères doivent être nommées de manière cohérente dans différentes tables.Il devrait être légal de tabasser quelqu'un qui ne fait pas cela.".Je n'ai jamais commis cette erreur mon ami Patrick, mais j'écris de manière générale.Et s’ils envisageaient ensemble de vous battre pour ça ?:)

Très tard à la fête mais je voulais quand même ajouter mon grain de sel sur les préfixes de colonnes

Il semble y avoir deux arguments principaux en faveur de l'utilisation de la norme de dénomination table_column (ou tableColumn) pour les colonnes, tous deux basés sur le fait que le nom de la colonne lui-même sera unique dans l'ensemble de votre base de données :

1) Vous n'êtes pas obligé de spécifier à tout moment des noms de tables et/ou des alias de colonnes dans vos requêtes

2) Vous pouvez facilement rechercher le nom de la colonne dans tout votre code

Je pense que les deux arguments sont erronés.La solution aux deux problèmes sans utiliser de préfixes est simple.Voici ma proposition :

Utilisez toujours le nom de la table dans votre SQL.Par exemple, utilisez toujours table.column au lieu de column.

Cela résout évidemment 2) car vous pouvez désormais simplement rechercher table.column au lieu de table_column.

Mais je t'entends crier, comment ça résout 1) ?Il s’agissait exactement d’éviter cela.Oui, c’était le cas, mais la solution était terriblement imparfaite.Pourquoi?Eh bien, la solution du préfixe se résume à :
Pour éviter d'avoir à spécifier table.column en cas d'ambiguïté, vous nommez toutes vos colonnes table_column !
Mais cela signifie que vous devrez désormais TOUJOURS écrire le nom de la colonne chaque fois que vous spécifiez une colonne.Mais si vous devez quand même le faire, quel est l'avantage de toujours écrire explicitement table.column ?Justement, il n'y a aucun avantage, c'est exactement le même nombre de caractères à taper.

modifier:oui, je suis conscient que nommer les colonnes avec le préfixe impose l'utilisation correcte alors que mon approche repose sur les programmeurs

Conventions de dénomination essentielles des bases de données (et style) (cliquez ici pour une description plus détaillée)

Les noms de table choisissent des noms courts et sans ambiguïté, en utilisant pas plus d'un ou deux mots distinguer les tables facilitent facilement la dénomination des noms de champ uniques ainsi que des tables de recherche et de liaison donnent des tables de noms singuliers, jamais pluriel (mise à jour:je suis toujours d'accord avec les raisons données pour cette convention, mais la plupart des gens aiment vraiment les noms de table au pluriel, j'ai donc adouci ma position)...suivez le lien ci-dessus s'il vous plaît

Noms de table au singulier.Disons que vous modélisiez une relation entre quelqu'un et son adresse.Par exemple, si vous lisez un DataModel, vous préférez «chaque personne peut vivre à 0,1 ou plusieurs adresses». ou «chaque personne peut vivre à 0,1 ou plusieurs adresses». Je pense qu'il est plus facile de pluraliser l'adresse, plutôt que de reformuler les gens en tant que personne.De plus, les noms collectifs sont assez souvent différents de la version singulière.


--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Ce sont les conventions qu'on m'a enseignées, mais vous devez vous adapter à tout ce que votre tuyau de développement utilise.

Pluriel.C'est un ensemble d'entités.
Oui.L'attribut est une représentation de la propriété singulière d'une entité.
Oui, le nom de table de préfixe permet une dénomination facilement traçable de tous les index de contraintes et alias de table.
Pascal Case pour les noms de tables et de colonnes, préfixe + TOUTES les majuscules pour les index et les contraintes.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow