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

Chaque fois que je crée 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:

1. Les noms de table doivent-ils être pluriels?
2. Les noms de colonne doivent-ils être singuliers?
3. Dois-je préfixer des tables ou des colonnes?
4. Dois-je utiliser n'importe quel cas pour nommer les articles?

Existe-t-il des recommandations pour nommer les éléments d'une base de données?

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.

1. Noms singuliers pour les tables
2. Noms singuliers pour les colonnes
3. Nom de schéma pour le préfixe des tables (ex: SchemeName.TableName)
4. Boîtier Pascal (alias boîtier camel supérieur)

Réponse tardive ici, mais en bref:

1. Ma préférence est plurielle
2. Oui
3. Tableaux : * Habituellement * aucun préfixe n'est préférable. Colonnes : Non.
4. Tables et colonnes: PascalCase.

Élaboration:

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

• Nommez vos clés primaires au format "[singularOfTableName] ID". Autrement dit, que votre nom de table soit Client ou Clients , la clé primaire doit être CustomerID .
• En outre, les clés étrangères doivent être nommées de manière cohérente dans différentes tables. Il devrait être légal de battre quelqu'un qui ne le fait pas. Je dirais que si les contraintes de clé étrangère définies sont souvent importantes, la dénomination de clé étrangère cohérente est toujours importante
• Votre base de données doit avoir des conventions internes . Même si dans les sections plus tard vous me verrez être très flexible, au sein d' une dénomination de base de données doit être très cohérente. Que votre table pour les clients s'appelle 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 vous devez ensuite 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.

• Les champs représentant le même type de données sur différentes tables doivent être nommés de la même manière. N'ayez pas Zip sur une table et ZipCode sur une autre.
• Pour séparer les mots de vos noms de table ou de colonne, utilisez PascalCasing. L'utilisation de camelCasing ne serait pas intrinsèquement problématique, mais ce n'est pas la convention et cela aurait l'air drôle. Je répondrai aux soulignements dans un instant. (Vous ne pouvez pas utiliser ALLCAPS comme autrefois. OBNOXIOUSTABLE.ANNOYING_COLUMN était correct dans DB2 il y a 20 ans, mais pas maintenant.)
• Ne raccourcissez ni n'abrégez artificiellement les mots. Il vaut mieux qu'un nom soit long et clair que court et déroutant. Les noms ultra-courts sont un souvenir des temps plus sombres et plus sauvages. Cus_AddRef. Qu'est-ce que c'est que ça? Référence du destinataire de la garde? Remboursement supplémentaire client? Référence d'adresse personnalisée?

(3) Ce que vous devriez considérer.

• Je pense vraiment que vous devriez avoir plusieurs noms pour les tableaux; certains pensent singulier. Lisez les arguments ailleurs. Les noms de colonnes doivent cependant être singuliers. Même si vous utilisez plusieurs noms de table, les tables qui représentent des combinaisons d'autres tables peuvent être au singulier. Par exemple, si vous avez des promotions et des articles table 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 soulignements de manière cohérente et dans un but particulier. Seuls les noms de tables générales doivent être suffisamment clairs avec PascalCasing; vous n'avez pas besoin de soulignements pour séparer les mots. Enregistrer souligne soit (a) pour indiquer une table associative ou (b) pour le préfixe, que j'aborderai dans la puce suivante.
• Le préfixe n'est ni bon ni mauvais. Ce n'est généralement pas le meilleur. Dans votre première ou 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 tableaux. Les tableaux ne correspondent pas facilement à vos catégories, et il peut en fait être plus difficile de trouver des tableaux. Avec l'expérience, vous pouvez planifier et appliquer un schéma de préfixe qui fait plus de bien que de mal. J'ai travaillé dans une base de données une fois où les tables de données ont commencé par tbl , les tables de configuration avec ctbl , les vues avec vew , proc's sp et udf's fnet quelques autres; il a été méticuleusement appliqué de manière cohérente, donc ça a bien marché. 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éfixe est également correct pour des situations spéciales, comme pour les tables temporaires que vous souhaitez mettre en évidence.
• Très rarement (voire jamais) voudriez-vous préfixer des colonnes.

D'accord, puisque nous pesons avec l'opinion:

Je pense que les noms de table doivent être pluriels. 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 un tableau des entités Personne Personnes (ou Personnes, selon ce qui vous plait).

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

SELECT person.Name
FROM People person

Un peu comme LINQ "from person in people select person.Name".

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

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

1. Toute norme de dénomination est préférable à aucune norme.
2. Il n'y a pas de "vrai" standard, nous avons tous nos préférences
3. S'il existe déjà une norme, utilisez-la. Ne créez pas une autre norme ou ne brouillez pas les normes existantes.

Nous utilisons des noms singuliers pour les tableaux. Les tableaux ont tendance à être préfixés avec 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 (par exemple reg_customer, reg_booking et regadmin_limits).

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

Le nom du champ de clé Foriegn 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 d'entité, préfixes et acronymes préférés et de donner 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.

1. Non. Une table doit être nommée d'après l'entité qu'elle représente. Personne, et non personne, c'est la façon dont vous vous référez à la personne que l'un des enregistrements représente.
2. Encore une fois, même chose. La colonne FirstName ne doit vraiment pas s'appeler FirstNames. Tout dépend de ce que vous voulez représenter avec la colonne.
3. NON.
4. Oui. Cassez-le pour plus de clarté. Si vous avez besoin de colonnes comme "FirstName", 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 d'être normatives.

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 de la collection. Idéalement, un nom collectif est utilisé: par exemple, Personnel. Le pluriel est également correct: Employés. Les noms incorrects incluent: Employé, tblEmployee et EmployeeTable."

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

J'entends constamment l'argument selon lequel la pluralisation ou non d'une table est une question de goût personnel et il n'y a pas de meilleure pratique. Je ne crois pas que ce soit vrai, surtout en tant que programmeur par opposition à un DBA. Pour autant que je sache, il n'y a aucune raison légitime de pluraliser un nom de table autre que "Cela a du sens pour moi car 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:

1. Il évite les bugs et les erreurs causés par plusieurs ambiguïtés. Les programmeurs ne sont pas exactement connus pour leur expertise en orthographe, et la pluralisation de certains mots est source de confusion. Par exemple, le pluriel se termine-t-il par «es» ou simplement «s»? S'agit-il de personnes ou de personnes? Lorsque vous travaillez sur un projet avec de grandes équipes, cela peut devenir un problème. Par exemple, une instance où un membre de l'équipe utilise la méthode incorrecte pour pluraliser une table qu'il crée. Au moment où j'interagis avec cette table, elle est utilisée partout dans le code auquel je n'ai pas accès ou que je mettrais trop de temps à corriger. Le résultat est que je dois me rappeler de mal orthographier la table chaque fois que je l'utilise. Quelque chose de très similaire à cela m'est arrivé. Plus il est facile pour chaque membre de l'équipe d'utiliser de manière cohérente et simple les informations exactes, corriger les noms de table sans erreurs ou avoir à rechercher constamment des noms de table, mieux c'est. La version singulière est beaucoup plus facile à gérer dans un environnement d'équipe.

2. Si vous utilisez la version singulière d'un nom de table ET le préfixe de la clé primaire avec le nom de la table, vous avez maintenant 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 avec un nom de table, concaténer "Id" à la fin, et vous avez maintenant la clé primaire de la table via le code, sans avoir à faire de 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 pluralisent les noms de table et préfixent les colonnes PK avec le nom de table utilisent la version singulière du nom de table dans le PK (par exemple les statuts et status_id),

3. Si vous rendez les noms de table singuliers, 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 à ...

4. Si vous rendez le nom de la table singulier, cela rend votre schéma de dénomination cohérent, organisé et facile à maintenir 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 le même nom exact. Cela vous permet de faire des recherches globales pour voir partout où les données sont utilisées. Lorsque vous pluralisez 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 il se transforme, dans la clé primaire). Il est tout simplement logique de ne pas avoir de cas où vos données sont appelées plurielles et certains cas singulières.

Pour résumer, si vous pluralisez les noms de vos tables, vous perdez toutes sortes d'avantages pour rendre votre code plus intelligent et plus facile à manipuler. Il peut même y avoir des cas où vous devez avoir des tables / tableaux de recherche pour convertir vos noms de table en objets ou en codes locaux que vous auriez pu éviter. Les noms de table singuliers, bien que se sentant peut-être un peu bizarres au début, offrent des avantages significatifs par rapport aux noms pluralisés et je pense que c'est la meilleure pratique.

notre préférence:

1. Les noms de table doivent-ils être pluriels?
   Jamais. Les arguments pour qu'il s'agisse d'une collection ont du sens, mais vous ne savez 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 vs souris, personne vs personnes, et nous n'avons même pas regardé d'autres langues.

   Update person set property = 'value'agit sur chaque personne dans le tableau.
   Select * from person where person.name = 'Greg'renvoie une collection / un ensemble de lignes de lignes de personne.

2. Les noms de colonne doivent-ils être singuliers?
   Habituellement, oui, sauf lorsque vous enfreignez les règles de normalisation.

3. Dois-je préfixer des tables ou des colonnes?
   Surtout une préférence de plateforme. Nous préférons préfixer les colonnes avec le nom de la table. Nous ne préfixons pas les tables, mais nous faisons des vues de préfixe (v_) et des procédures stockées (sp_ ou f_ (fonction)). Cela aide les personnes qui souhaitent essayer upday 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 aussi un excellent moyen d'éviter la collision de mots clés (delivery.from se casse, mais delivery_from ne le fait pas).

   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 de 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 MM entre type_client et catégorie_client (seuls certains types sont disponibles pour certaines catégories)

   customer_category_customer_type_id

   ... est un peu (!) sur le côté long.

4. Dois-je utiliser n'importe quel cas pour nommer les articles? Oui - en minuscules :), avec des traits de soulignement. Ce sont très lisibles et multi-plateformes. Avec 3 ci-dessus, il est également logique.

   La plupart d'entre eux sont cependant des préférences. - Tant que vous êtes cohérent, il doit être prévisible pour quiconque doit le lire.

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

J'ai blogué à ce sujet il y a quelque temps: Conventions de dénomination ISO-11179

Je sais que c'est tard dans le jeu, et la question a déjà été très bien répondu, mais je veux donner mon avis sur # 3 concernant le préfixe des noms de colonne.

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 tableaux "client" et "adresse", allons-y avec les préfixes de "cust" et "addr", respectivement. "client" aurait "cust_id", "cust_name", etc. dedans. "adresse" aurait "addr_id", "addr_cust_id" (FK retour au client), "addr_street", etc. dedans.

Lorsque j'ai été présenté pour la première fois avec cette norme, j'étais complètement opposé à cela; Je détestais l'idée. Je ne pouvais pas supporter l'idée de toute cette frappe et redondance supplémentaires. Maintenant, j'ai assez d'expérience avec ça pour ne plus jamais y retourner.

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 rechercher l'ensemble de votre base de code et trouver de manière fiable chaque ligne de code qui touche une colonne particulière.

L'avantage du n ° 1 est incroyablement énorme. Je peux déprécier 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 dire 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ù cela a transformé un projet potentiellement énorme en un projet simple, ni le nombre d'heures que nous avons économisées dans le 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 table doivent être singuliers.

Bien que cela semble logique pour la sélection simple ( 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 vraiment l'ensemble de cette entité, cela a plus de sens une fois que vous utilisez set-logic:

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

Cette dernière ligne, la logique réelle de la jointure, semble confuse avec plusieurs noms de table.

Je ne suis pas sûr de toujours utiliser un alias (comme le suggère Matt) clarifie 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 les distinguer assez bien. Vous voulez que les requêtes soient rapides à saisir et simples - les préfixes ajoutent une complexité inutile.

4) Tout ce que vous voulez, je vous suggère CapitalCase

Je ne pense pas qu'il y ait un ensemble de lignes directrices absolues sur ces points.

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

À mon avis:

1. Les noms de table doivent être pluriels.
2. Les noms de colonne doivent être singuliers.
3. Non.
4. Soit CamelCase (mon préféré) ou underscore_separated pour les noms de table et les noms de colonne.

Cependant, comme cela a été mentionné, toute convention vaut mieux qu’aucune convention. Peu importe comment vous choisissez de le faire, documentez-le afin que les modifications futures respectent les mêmes conventions.

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

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

Bien sûr, il est bon de chercher des informations sur les normes à ce sujet, c'est ce que vous demandez, mais ne vous inquiétez pas ou ne vous inquiétez pas du nombre de réponses différentes que vous pourriez obtenir: choisissez celle qui vous semble la meilleure.

Au cas où, voici mes réponses:

1. Oui. Une table est un groupe d' enregistrements , d' enseignants ou d' acteurs , donc ... pluriel.
2. Oui.
3. Je ne les utilise pas.
4. La base de données que j'utilise le plus souvent - Firebird - garde tout en majuscules, donc peu importe. Quoi qu'il en soit, lorsque je programme, j'écris les noms d'une manière plus facile à lire, comme releaseYear .

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

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 nommage prend du temps à évoluer, mais une fois qu'elle est en place, elle permet à l'équipe d'avancer avec un langage commun. Une bonne convention de dénomination se développe naturellement avec le projet. Une bonne convention de dénomination résiste facilement aux changements pendant 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:

1. Oui, les noms de table doivent être pluriels lorsqu'ils font référence à un ensemble d' opérations , de titres ou de contreparties par exemple.
2. Oui.
3. Oui. Les tables SQL sont préfixées par tb_, les vues sont préfixées vw_, les procédures stockées sont préfixées usp_ et les déclencheurs sont préfixés tg_ suivi du nom de la base de données.
4. Le nom de la colonne doit être en minuscules séparés par un trait de soulignement.

Le nommage est 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 prend la responsabilité des normes de nommage et s'assure que les problèmes de nommage comme sec_id , sec_value et security_id sont résolus tôt avant d'être au projet. .

Alors, quels sont les principes de base d'une bonne convention de dénomination et de normes: -

• Utilisez la langue de votre client et de votre domaine de solution
• Soyez descriptif
• Être cohérent
• Lever l'ambiguïté, réfléchir et refactoriser
• N'utilisez pas d'abréviations à moins qu'elles ne soient claires pour tout le monde
• N'utilisez pas de 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 pouvais suivre plutôt que de devoir compter sur une spécification partiellement définie.

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

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

Les noms de table doivent toujours être singuliers, 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 ou le deuxième mot ou les deux. C'est la logique - Object.instance, pas objects.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'ils sont composés de deux ou plusieurs noms.

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 est singulier.

Nom de la colonne: Il ne doit être singulier que s'il transmet qu'il contiendra une valeur atomique et confirmera la théorie de la normalisation. Si toutefois il existe n nombre de propriétés du même type, elles doivent être suffixées de 1, 2, ..., n, etc.

Préfixer les tables / colonnes: c'est un sujet énorme, nous en discuterons plus tard.

Boîtier: il devrait s'agir d'un étui Camel

Mon ami, Patrick Karcher , je vous demande de ne pas écrire quoi que ce soit 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 battre quelqu'un qui ne faites cela. ". Je n'ai jamais fait cette erreur mon ami Patrick, mais j'écris généralement. Et s'ils prévoient ensemble de vous battre pour ça? :)

Très tard pour la fête mais je voulais quand même ajouter mes deux cents sur les préfixes de colonne

Il semble y avoir deux arguments principaux pour utiliser la norme de dénomination table_column (ou tableColumn) pour les colonnes, toutes deux basées 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'avez pas à spécifier à tout moment les noms de table et / ou les alias de colonne dans vos requêtes

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

Je pense que les deux arguments sont viciés. La solution aux deux problèmes sans utiliser de préfixes est facile. 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 maintenant simplement rechercher table.column au lieu de table_column.

Mais je peux vous entendre crier, comment ça résout 1)? Il s'agissait exactement d'éviter cela. Oui, c'était vrai, mais la solution était horriblement défectueuse. Pourquoi? Eh bien, la solution de 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 le faire de toute façon, quel est l'avantage par rapport à l'écriture toujours explicite de table.column? Exactement, il n'y a aucun avantage, c'est exactement le même nombre de caractères à taper.

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

Conventions de dénomination 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, les tables de distinction facilitent facilement la dénomination des noms de champ uniques ainsi que la recherche et les tables de liaison donnent aux tables des noms singuliers, jamais pluriels (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. Supposons que vous modélisiez une relation entre une personne et son adresse. Par exemple, si vous lisez un modèle de données, préférez-vous que «chaque personne puisse 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 similaires à 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 qui m'ont été enseignées, mais vous devez vous adapter à tout ce que vous utilisez pour développer vos tuyaux.

1. Pluriel. C'est une collection d'entités.
2. Oui. L'attribut est une représentation de la propriété singulière d'une entité.
3. Oui, le nom de table de préfixe permet de nommer facilement tous les index de contraintes et les alias de table.
4. Cas Pascal pour les noms de table et de colonne, préfixe + toutes les majuscules pour les index et les contraintes.