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

Réponse tardive ici, mais en bref:

1. Mon préférence est le pluriel
2. Oui
3. Tables : * habituellement * aucun préfixe n'est le meilleur. Colonnes : Non.
4. les deux 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 en utilisant "[singularOfTableName]ID " format. Autrement dit, si votre nom de table est Customer ou Customers, 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, le nommage cohérent de la clé étrangère est TOUJOURS important
• Vous base de données doit avoir conventions internes. Même si dans les sections suivantes, vous me verrez être très flexible, dans un nommage de base de données doit être très cohérent . Que votre table pour les clients soit appelée clients ou client est moins important que vous le faites de la même manière dans la même base de données. Et vous pouvez retourner une pièce pour déterminer comment utiliser les traits de soulignement, mais alors vous devez continuer à les utiliser de la même manière. Si vous ne faites pas cela, vous êtes un mauvais personne qui devrait avoir une faible estime de soi.

(2) Ce que vous devriez faire.

• les champs représentant le même type de données sur différentes tables devraient être nommés de la même manière. Ne pas avoir Zip sur une table et Code Postal sur un autre.
• pour séparer les mots dans les 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 vais aborder les traits de soulignement dans un instant. (Vous ne pouvez pas utiliser ALLCAPS comme dans les temps anciens. OBNOXIOUSTABLE.ANNOYING_COLUMN était correct dans DB2 il y a 20 ans, mais pas maintenant.)
• Ne pas raccourcir ou abréger artificiellement des mots. Il vaut mieux qu'un nom soit long et clair que court et déroutant. Ultra-short names est un holdover de temps plus sombres et plus sauvages. Cus_AddRef. Ce qui sur terre est qui? Référence Du Destinataire Dépositaire? Remboursement Supplémentaire Du Client? Référence D'Adresse Personnalisée?

(3) Ce que vous devraient envisager.

• je pense vraiment que vous devriez avoir des noms pluriels pour les tables; certains pensent singulier. Lisez les arguments ailleurs. Les noms de colonne 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 un Promotions et d'Éléments de tableau, un tableau représentant un élément faisant partie d'une promotion pourrait être Promotions_Items, mais il pourrait aussi légitimement être Promotion_Items je pense (reflétant la relation un à plusieurs).
• Utilisez des traits de soulignement de manière cohérente et dans un but particulier. Juste les noms de tables générales devraient être assez clairs avec PascalCasing; vous n'avez pas besoin de traits de soulignement pour séparer les mots. Save underscores soit (a) pour indiquer une table associative ou (b) pour le préfixe, que je vais aborder dans la puce suivante.
• le préfixe n'est ni bon ni mauvais. Il généralement n'est pas mieux. Dans votre première db ou deux, je ne suggérerait pas d'utiliser des préfixes pour le regroupement thématique général des tableaux. Les Tables finissent par ne pas correspondre facilement à vos catégories, et cela peut en fait rendre plus difficile de trouver des tables. 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 db une fois où les tables de données a commencé avec tbl, config tables avec ctbl, vues avec vew, proc sp, et de l'udf, du fn, et quelques autres; elle a été méticuleusement, appliqué de manière cohérente, cela a bien fonctionné. La seule fois où vous avez besoin de préfixes est lorsque vous avez des solutions vraiment séparées 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 tables. Le préfixe est également correct pour des situations spéciales, comme pour les tables temporaires que vous voulez démarquer.
• très rarement (si jamais) voudriez-vous préfixe colonnes.

Ok, puisque nous pesons avec opinion:

Je crois 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 la table représente la collection. Donc, j'appellerais une table D'entités Person People (ou Persons, tout ce qui prend votre fantaisie).

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

SELECT person.Name
FROM People person

Un peu comme LINQ " de person in people sélectionner person.Name".

Quant à 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 considérées sont:

1. toute norme de nommage est meilleure qu'aucune norme.
2. Il n'y a pas de "vrai" standard, nous avons tous nos préférences
3. S'il y a déjà une norme en place, utilisez-la. Ne pas créer une autre norme ou brouiller les normes existantes.

Nous utilisons des noms singuliers pour les tables. Les Tables ont tendance à être préfixées par le nom du système (ou son acronyme). Ceci est utile si le système complexe que vous pouvez changer le préfixe pour regrouper les tables ensemble logiquement (ie. reg_customer, reg_booking et regadmin_limits).

Pour les champs nous nous attendons à des noms de champs à inclure le préfixe/acryonm de la table (c'est à dire cust_address1) et nous préférons également l'utilisation d'un ensemble de suffixes ( _id pour le PK, _cd pour "code", _nm pour "nom", _nb de "nombre", _dt "Date").

Le nom du champ Clé Foriegn doit être le même que le 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és, 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" ce que 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, pas des personnes, c'est comme ça que vous vous référeriez à la personne que représente l'un des dossiers.
2. encore une fois, même chose. La colonne FirstName ne devrait vraiment pas être appelée FirstNames. Tout dépend de ce que vous voulez représenter avec la colonne.
3. non.
4. Oui. Cas pour plus de clarté. Si vous avez besoin d'avoir des colonnes comme "Prénom", le boîtier sera plus facile à lire.

Ok. C'est mon $ 0.02

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

Voir l'élément de Données nom sur Wikipédia:

" les Tables sont des Collections d'entités et suivent les directives de nommage des collections. Idéalement, un nom collectif est utilisé: par exemple., Personnel. Le pluriel est également correct: les 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 mieux avec un nom singulier par exemple, une table de configuration. Et la cohérence est de la plus haute importance: vérifiez si vous magasinez a une convention et, si oui, suivez-la; si vous ne l'aimez pas, faites une analyse de rentabilisation pour la faire changer plutôt que d'être le Lone ranger.

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 rendent la dénomination inutilement compliquée. 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 / jeu de lignes de person rangée.

2. Les noms de colonnes devraient-ils être singuliers?
   Habituellement, Oui, sauf lorsque vous enfreignez les règles de normalisation.

3. Devrais-je préfixer des tables ou des colonnes?
   Surtout 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 stored_procedures (sp_ ou f_ (function)). Cela aide les gens qui veulent essayer de mettre à jour v_person.âge qui est en fait un champ calculé dans une vue (qui ne peut pas être Mise à jour de toute façon).

   C'est aussi un excellent moyen d'éviter la collision de mots clés (livraison.des pauses, mais delivery_from ne le fait pas).

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

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... est très lisible et explicite. Cela peut 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 vous voyez déjà '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 (!) sur le côté long.

4. Devrais-je utiliser n'importe quel cas pour nommer des éléments? Oui-minuscules:), avec des traits de soulignement. Ceux-ci sont très lisibles et multi-plateforme. Ensemble avec 3 ci-dessus, il est aussi judicieux.

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

Jetez un oeil à 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 un moment ici: conventions de nommage ISO-11179

J'entends l'argument tout le temps que si une table est pluralisée ou non 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 pas de raisons légitimes de pluraliser 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:

1. Il évite les bugs et les erreurs causées par des ambiguïtés plurielles. 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 mot 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 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 I ne pas avoir accès à ou prendrait trop de temps à réparer. Le résultat est que je dois me rappeler d'épeler la table mal 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 facile les noms de table exacts et corrects sans erreurs ou d'avoir à rechercher des noms de table tout le temps, mieux c'est. La version singulière est beaucoup plus facile à manipuler dans un environnement d'équipe.

2. Si vous utilisez la version d'un singulier nom de la table et 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 une requête supplémentaire. Ou vous pouvez couper "Id" de 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 le primaire clé, alors 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éfixe les colonnes PK avec le nom de la table utilisent la version singulière du nom de la table dans le PK (par exemple statuts et statusId), ce qui rend impossible de le faire du tout.

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 soignées, comme instancier une classe en n'ayant 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 nommage 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, en tant que nom de classe ou en tant que 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 certains cas où vos données sont appelées pluriel et certaines instances singulières.

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

Je sais que c'est tard pour le jeu, et la question a déjà été très bien répondue, mais je veux donner mon avis sur #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 "customer" et "address", allons 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.

Quand on m'a présenté cette norme pour la première fois, j'étais contre elle; je détestais l'idée. Je ne pouvais pas supporter l'idée de tout ce typage supplémentaire et de la redondance. Maintenant, j'ai eu assez d'expérience avec ça que je n'y retournerais jamais.

Le résultat est que toutes les colonnes dans 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 toute votre base de code et trouver de manière fiable chaque ligne de code qui touche une colonne particulière.

L'avantage de #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 que cela a transformé un projet potentiellement énorme en un 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 n'avez qu'à utiliser des alias de table 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 sur ceux-ci sont:

1) non, les noms de table doivent être singuliers.

Bien qu'il semble logique pour la sélection simple (select * from Orders), Il est moins logique 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) efface jusqu'.

2) ils doivent être singuliers car ils ne détiennent que 1 propriété

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

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

Je ne pense pas qu'il y ait un ensemble de directives absolues sur l'un de ces.

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

, À mon avis:

1. les noms de Table doivent être au pluriel.
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 il 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 suivent les mêmes conventions.

1. certainement garder les noms de table singulier, personne pas les gens
   1. même chose ici
   2. Non. J'ai vu des préfixes terribles, allant jusqu'à indiquer ce qui traitait d'une table (tbl_) ou d'une procédure de magasin d'utilisateurs (usp_). Ceci suivi du nom de la base de données... Ne pas le faire!
   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 beaucoup plus important d'avoir une convention de nommage alors, comment exactement la convention de nommage est.

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 - s'y tenir.

Bien sûr, il est bon de chercher des informations sur les normes à ce sujet, ce que vous demandez, mais ne recevez pas anxieux ou inquiet du nombre de réponses différentes que vous pourriez obtenir: choisissez celle qui vous semble la mieux adaptée.

Juste au cas où, voici mes réponses:

1. Oui. Une table est un groupe de enregistrements, les enseignants ou acteurs, donc... au 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 ça n'a pas d'importance. Quoi qu'il en soit, quand je programmation, j'écris les noms d'une manière qui c'est plus facile à lire, comme releaseYear.

Les conventions de nommage 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 nommage se développe organiquement avec le projet. Une bonne convention de nommage s'adapte facilement aux changements pendant la phase la plus longue et la plus importante du cycle de vie du logiciel - la gestion des services dans production.

Voici mes réponses:

1. Oui, les noms de table devrait être au pluriel quand ils se réfèrent à un ensemble de métiers, titres, ou contreparties, par exemple.
2. Oui.
3. Oui. Les tables SQL sont préfixées avec 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_ suivis du nom de la base de données.
4. le nom de la colonne doit être séparé en minuscules 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 qu'ils ne soient intégrés au projet.

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

• Utilisez la langue de votre client et votre domaine de solution
• Être descriptif
• soyez cohérent
• désambiguïser, réfléchir et refactoriser
• N'utilisez pas d'abréviations à moins qu'elles sont clairs pour tout le monde
• N'utilisez pas de mots-clés réservés SQL comme noms des colonnes

Voici un lien qui offre quelques choix. Je cherchais une spécification simple que je pouvais suivre plutôt que d'avoir à compter sur une spécification partiellement définie.

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

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ésigner un groupe d'oiseaux. Pas besoin de pluriel. Lorsqu'un nom de table est composé de deux noms et que la convention de nommage est au pluriel, il devient difficile de savoir si le nom pluriel doit être le premier mot ou le deuxième mot ou les deux. C'est la logique de l'Objet.par exemple, pas les objets.instance. Ou TableName.colonne, pas TableNames.la colonne(s). Microsoft SQL n'est pas le cas sensible, 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 noms ou plus.

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

Nom de la colonne: il devrait être singulier seulement alors il transmet qu'il tiendra une valeur atomique et confirmera à la théorie de normalisation. Si toutefois, il y a n nombre de même type de propriétés, alors ils doivent être suffixés avec 1, 2,..., n, etc.

Préfixer les Tables / colonnes: c'est un sujet énorme, discutera tard.

Boîtier: il devrait être Chameau cas

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 le fait pas.". Je ne l'ai jamais fait cette erreur Mon ami Patrick, mais je vous écris en général. Et s'ils prévoient ensemble de vous battre pour ça? :)

Très en retard à 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 le standard de nommage 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 toute votre base de données:

1) vous n'avez pas besoin de spécifier des noms de table et/ou des alias de colonne dans vos requêtes tout le temps

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

Je pensez que les deux arguments sont viciés. La solution pour les 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 la table.la colonne de la place de la colonne.

Il résout évidemment 2) comme vous pouvez maintenant simplement rechercher la table.colonne au lieu de table_column.

Mais je peux vous entendre crier, comment ça résout 1)? C'était exactement sur la façon d'éviter cela. Oui, c'était, mais la solution était horriblement imparfaite. Pourquoi? Eh bien, le la solution de préfixe se résume à:
Pour éviter d'avoir à spécifier la table.colonne quand il y a 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 à la table d'écriture toujours explicitement.la colonne? Exactement, il n'y a aucun avantage, c'est exactement le même nombre de caractères à taper.

Edit: Oui, je suis conscient que nommer les colonnes avec le prefix applique l'utilisation correcte alors que mon approche repose sur les programmeurs

Conventions essentielles de nommage de base de données (et Style) (Cliquez ici pour une description plus détaillée)

Noms de Table choisissez des noms courts et sans ambiguïté, en n'utilisant pas plus d'un ou deux mots distinguer facilement les tables facilite le nommage des noms de champs uniques ainsi que la recherche et les tables de liaison donnez des noms singuliers aux tables, jamais au 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 pluriels, donc j'ai adouci ma position)... suivez le lien ci-dessus s'il vous plaît

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

Noms de Table singulier. Disons que vous modélisiez une relation réelle entre quelqu'un et son adresse. Par exemple, si vous lisez un datamodel préférez-vous "chaque personne peut vivre à 0,1 ou plusieurs adresses.' ou "chaque peuple peut vivre à 0,1 ou plusieurs adresses.' Je pense qu'il est plus facile de pluraliser l'adresse, plutôt que d'avoir à reformuler les gens en tant que personne. De plus les noms collectifs sont assez souvent dissimlar à 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.

1. pluriel. C'est une collection d'entités.
2. Oui. L'attribut est une représentation de la singulière propriété d'une entité.
3. Oui, prefix table name permet un nommage facilement traçable de tous les index de contraintes et 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.