Conventions de dénomination de firebase database, de table et de colonne?

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 objects de firebase database.

1. Noms singuliers pour les tableaux
2. Noms singuliers pour les colonnes
3. Nom du schéma pour le préfixe des tables (Ex: SchemeName.TableName)
4. Cas de Pascal (cas du chameau supérieur)

Réponse tardive ici, mais en bref:

1. Ma préférence est plurielle
2. Oui
3. Tableaux : * Généralement * aucun préfixe n’est préférable. 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 le format “[singularOfTableName] ID”. En d’autres termes, que votre nom de table soit Customer ou Customers , la clé primaire doit être CustomerID .
• 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 soutiendrais que, bien que les contraintes de clé étrangère définies soient souvent importantes, la dénomination cohérente des clés étrangères est toujours importante.
• Votre firebase database doit avoir des conventions internes . Même si dans les sections suivantes, vous constaterez que je suis très flexible, les noms de bases de données doivent être très cohérents. Que votre table pour les clients soit appelée Clients ou Client est moins importante que la même procédure dans la même firebase database. Et vous pouvez retourner une pièce pour déterminer comment utiliser les traits de soulignement, mais vous devez 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 des tables différentes doivent être nommés de la même manière. Ne pas avoir Zip sur une table et ZipCode sur une autre.
• Pour séparer les mots dans vos noms de table ou de colonne, utilisez PascalCasing. L’utilisation de camelCasing ne serait pas insortingnsèquement problématique, mais ce n’est pas la convention et ce serait drôle. Je vais aborder les points faibles 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 pas raccourcir ou abréger artificiellement les mots. Il est préférable qu’un nom soit long et clair plutôt que court et déroutant. Les noms ultra-courts sont un gage de 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 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 pluriels pour les tables; certains pensent singulièrement. Lisez les arguments ailleurs. Les noms de colonne doivent cependant être singuliers. Même si vous utilisez plusieurs noms de table, les tableaux représentant des combinaisons d’autres tables peuvent être au singulier. Par exemple, si vous avez une table Promotions et une table Items , une table représentant un élément faisant partie d’une promotion pourrait être Promotions_Items, mais cela pourrait aussi être légitimement Promotion_Items (reflétant la relation un-à-plusieurs).
• Utilisez les traits de soulignement de manière cohérente et dans un but particulier. Seuls les noms de tables généraux devraient être suffisamment clairs avec PascalCasing; vous n’avez pas besoin de traits de soulignement pour séparer les mots. Enregistrer les soulignements (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. Ce n’est généralement pas la meilleure. Dans votre première ou deuxième firebase database, je ne suggère pas d’utiliser des préfixes pour le regroupement thématique général des tables. Les tableaux finissent par ne pas convenir facilement à vos catégories et peuvent en fait rendre la recherche des tableaux plus difficile . 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é une fois dans une firebase database où les tables de données commençaient par tbl , les tables de configuration avec ctbl , les vues avec vew , les sp de proc et les fn de udf, et quelques autres; c’était méticuleusement, systématiquement appliqué, donc ça a marché bien. Le seul moment 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 firebase database; les préfixer peut être très utile pour regrouper les tableaux. Le préfixage est également acceptable pour les situations spéciales, comme pour les tables temporaires que vous souhaitez faire ressortir.
• Très rarement (voire jamais) voudriez-vous préfixer des colonnes.

Ok, puisque nous pesons dans l’opinion:

Je crois que les noms de tables doivent être au pluriel. Les tableaux sont une collection (un tableau) d’entités. Chaque ligne représente une entité unique et la table représente la collection. Donc, j’appellerais une table de personnes personnes (ou personnes, tout ce qui prend votre fantaisie).

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

 SELECT person.Name FROM People person 

Un peu comme LINQ “de personne dans les gens, sélectionnez personne.Nom”.

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

Je travaille dans une équipe de support de firebase database avec trois DBA et nos options envisagées sont les suivantes:

1. Toute norme de nommage est préférable à aucune norme.
2. Il n’y a pas de standard “un vrai”, 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 bougez pas les normes existantes.

Nous utilisons des noms singuliers pour les tableaux. Les tableaux ont tendance à être précédés du nom du système (ou de 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 champs incluent le préfixe / acryonm de la table (cust_address1) et nous préférons également utiliser un ensemble standard de suffixes (_id pour la PK, _cd pour “code”, _nm pour “name “, _nb pour” nombre “, _dt pour” Date “).

Le nom du champ de clé Foriegn doit être identique à celui de la 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 faire référence au document plutôt que de “deviner” ce que la table et les champs doivent être appelés.

1. Une table doit être nommée d’après l’entité qu’elle représente. Personne, pas des personnes est la façon dont vous vous référez à celui que l’un des dossiers représente.
2. Encore une fois, même chose. La colonne Prénom ne doit 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 de colonnes comme “FirstName”, le casse rendra la lecture plus facile.

D’accord. C’est mon $ 0.02

Je suis également favorable à une convention de dénomination de style ISO / IEC 11179, notant que ce sont des lignes direcsortingces plutôt que d’être normatives.

Voir Nom de l’élément de données sur Wikipedia :

“Les tables sont des collections d’entités et suivent les directives de dénomination de la collection. Dans l’idéal, un nom collectif est utilisé: par exemple, Personnel. Le pluriel est également correct: Employés. Noms incorrects: 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 un tableau de configuration. Et la cohérence est de la plus haute importance: vérifiez si votre boutique a une convention et, si oui, suivez-la; Si vous ne l’aimez pas, alors faites une parsing de rentabilisation pour la faire changer plutôt que d’être le seul garde.

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 contre souris, personne contre personnes, et nous n’avons même pas regardé d’autres langues.

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

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

3. 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 faisons des vues de préfixe (v_) et des stock_procedures (sp_ ou f_ (fonction)). Cela aide les personnes qui veulent tester v_person.age qui est en fait un champ calculé dans une vue (qui ne peut de toute façon pas être mis à jour).

   C’est aussi un excellent moyen d’éviter les collisions de mots-clés (livraison.from tombe en panne, mais livraison_ne pas).

   Cela rend le code plus détaillé, 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 déraper si:

   customer.customer_customer_type_id

   indique une relation entre le client et la table customer_type, indique la clé primaire dans la table customer_type (customer_type_id) et si vous voyez jamais ‘id_client_client_de_customer’ lors du débogage d’une requête, vous savez instantanément d’où elle provient (table customer).

   ou où vous avez une relation MM 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.

4. Dois-je utiliser des cas particuliers pour nommer des éléments? Oui – minuscule :), avec des traits de soulignement. Celles-ci sont très lisibles et multiplates-formes. Avec 3 ci-dessus, cela a aussi du sens.

   La plupart de ces préférences sont cependant. – Tant que vous êtes cohérent, cela devrait être prévisible pour quiconque doit le lire.

Jetez un coup d’œ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’ai blogué à ce sujet à un moment donné ici: Conventions de dénomination ISO-11179

J’entends tout le temps l’argument que le fait de savoir si un tableau est pluralisé est une question de goût personnel et qu’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. 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’objects”, alors qu’il y a des gains légitimes en codes singuliers. Par exemple:

1. Il évite les bugs et les erreurs causés par les ambiguïtés plurielles. Les programmeurs ne sont pas exactement connus pour leur expertise en orthographe, et la pluralisation de certains mots est déroutante. 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 auquel je n’ai pas access ou que je mettrais trop de temps à corriger. Le résultat est que je dois me souvenir d’épeler la table à chaque fois que je l’utilise. Quelque chose de très similaire à ceci m’est arrivé. Plus vous pouvez faire en sorte que chaque membre de l’équipe puisse utiliser les noms de table exacts et exacts sans erreur de manière cohérente et facile, ou mieux rechercher les noms de table, mieux ce sera. 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 préfixez 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 la clé primaire, vous ne pouvez pas via le code déterminer le nom de la table à partir de la clé primaire. En outre, la plupart des utilisateurs de noms de tables et de colonnes PK préfixés par le nom de la table utilisent la version singulière du nom de la table dans la clé (par exemple, statuses et statusId), ce qui rend cette opération impossible.

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 l’instanciation d’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 définissez le nom de la table au singulier, cela rend votre schéma de dénomination cohérent, organisé et facile à gérer à chaque emplacement. Vous savez que dans chaque code de votre code, qu’il s’agisse d’un nom de colonne, d’un nom de classe ou du nom de la table, c’est exactement le même nom. 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 devient, dans la clé primaire). Il est juste logique de ne pas avoir des cas où vos données sont appelées pluriel et certaines instances singulières.

En résumé, si vous pluralisez les noms de tables, vous perdez toutes sortes d’avantages pour rendre votre code plus intelligent et plus facile à gérer. Il peut même y avoir des cas où vous devez avoir des tables de recherche / tableaux pour convertir vos noms de tables en objects ou en noms de code locaux que vous auriez pu éviter. Les noms de table singuliers, même s’ils se sentent peut-être un peu bizarres au début, offrent des avantages significatifs par rapport aux noms pluriels et je crois que ce sont les meilleures pratiques.

Je sais que c’est tard pour le jeu, et la question a déjà été très bien résolue, 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, avec les tables “client” et “adresse”, allons avec les préfixes “cust” et “addr”, respectivement. “client” aurait “cust_id”, “cust_name”, etc. “adresse” aurait “addr_id”, “addr_cust_id” (FK retour au client), “addr_street”, etc.

Lorsque j’ai été présenté pour la première fois avec cette norme, j’étais contre-indiqué; Je détestais l’idée. Je ne pouvais pas supporter l’idée de toute cette frappe supplémentaire et de cette redondance. Maintenant, j’ai assez d’expérience avec ça, je n’y retournerais jamais.

Le résultat est que toutes les colonnes de votre schéma de firebase database 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 votre base de code entière 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 de pouvoir retirer la colonne du schéma en toute sécurité. Je peux changer le sens d’une colonne et savoir exactement quel code doit être remanié. 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é dans le travail de développement.

Un autre avantage relativement mineur réside dans le fait que vous n’avez à utiliser que des alias de table lorsque vous vous joignez à vous-même:

 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 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 firebase database est vraiment l’ensemble de cette entité, cela fait plus de sens une fois que vous utilisez la logique set:

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

2) Ils devraient être singuliers car ils ne contiennent que 1 propriété

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

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

Je ne pense pas qu’il y ait un ensemble de lignes direcsortingces absolues sur aucun de ces points.

Tant que ce que vous choisissez est cohérent à travers l’application ou la firebase database, je ne pense pas que ce soit vraiment important.

À mon avis:

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

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 suivent les mêmes conventions.

1. Gardez les noms de table singuliers, personne non
   2. Pareil ici
   3. Non. J’ai vu des préfixes terribles, allant jusqu’à dire ce qui était en jeu, une table (tbl_) ou une procédure de magasin utilisateur (usp_). Cela suivi du nom de la firebase database … Ne le faites pas!
   4. 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 dénomination que la convention de dénomination.

Comme il n’y a pas de bonne réponse à cela, vous devriez prendre un peu de temps (mais pas trop) et choisir vos propres conventions.

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

Juste 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 firebase database que j’utilise le plus souvent – Firebird – garde tout en majuscule, donc peu importe. En tout cas, quand je programme, j’écris les noms de manière à ce qu’ils soient plus faciles à lire, comme releaseYear .

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

Une bonne convention de nommage prend du temps pour évoluer, mais une fois en place, cela permet à l’équipe de progresser dans un langage commun. Une bonne convention de nommage se développe organiquement avec le projet. Une bonne convention de dénomination permet de gérer facilement les 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:

1. Oui, les noms de table doivent être pluriels lorsqu’ils font référence à un ensemble de transactions , de titres ou de contreparties, par exemple.
2. Oui.
3. Oui. Les tables SQL ont le préfixe 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 par tg_ suivi du nom de la firebase database.
4. Le nom de la colonne doit être séparé en minuscules par un trait de soulignement.

La dénomination est difficile mais dans chaque organisation, il y a quelqu’un qui peut nommer des choses et dans chaque équipe logicielle, il doit y avoir quelqu’un qui prend en charge les normes de dénomination et sec_id , sec_value et security_id. .

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

• Utilisez la langue de votre client et votre domaine de solution
• Soyez descriptif
• Être cohérent
• Désambiguïser, réfléchir et refactoriser
• N’utilisez pas d’abréviations à moins qu’elles ne soient claires pour tout le monde
• N’utilisez pas les mots-clés réservés SQL comme noms de colonnes

Voici un lien qui offre 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

Les noms de table doivent toujours être singuliers, car ils représentent un ensemble d’objects. Comme vous le dites, un groupe de moutons ou de troupeaux 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 du pluriel doit être le premier mot, 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 tables, 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 devrait être singulier, car il s’agit d’une entité singulière représentant un object du monde réel et non des objects, ce qui est unique.

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

Préfixing Tables / Colonnes: C’est un sujet énorme, discutera plus tard.

Boîtier: il devrait être cas de chameau

Mon ami, Pasortingck Karcher , je vous prie de ne pas écrire quoi que ce soit qui puisse choquer 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érents tableaux. faites ceci. ” Je n’ai jamais fait cette erreur mon ami Pasortingck, mais j’écris généralement. Et s’ils envisageaient ensemble de te battre pour ça? 🙂

Très tard à la fête mais je voulais toujours append mes deux cents sur les préfixes de colonne

Il semble y avoir deux arguments principaux pour utiliser la norme de nommage table_column (ou tableColumn) pour les colonnes, tous deux basés sur le fait que le nom de la colonne sera unique dans toute votre firebase database:

1) Vous n’avez pas besoin de spécifier des noms de tables et / ou des alias de colonnes dans vos requêtes tout le temps

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

Je pense que les deux arguments sont erroné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 table.column au lieu de colonne.

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

Mais je peux vous entendre crier, comment résout-il 1)? C’était exactement pour éviter cela. Oui, mais la solution était horriblement imparfaite. Pourquoi? Eh bien, la solution de préfixe se résume à:
Pour éviter d’avoir à spécifier table.column en cas d’ambiguïté, 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 de toujours écrire explicitement 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 nommer les colonnes avec le préfixe impose l’utilisation correcte alors que mon approche repose sur les programmeurs

Essential Database Naming Conventions (and Style) (click here for more detailed description)

table names choose short, unambiguous names, using no more than one or two words distinguish tables easily facilitates the naming of unique field names as well as lookup and linking tables give tables singular names, never plural (update: i still agree with the reasons given for this convention, but most people really like plural table names, so i’ve softened my stance)… follow the link above please

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

Table names singular. Let’s say you were modelling a realtionship between someone and their address. For example, if you are reading a datamodel would you prefer ‘each person may live at 0,1 or many address.’ or ‘each people may live at 0,1 or many addresses.’ I think its easier to pluralise address, rather than have to rephrase people as person. Plus collective nouns are quite often dissimlar to the singular version.

 --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 ); 

These are the conventions I was taught, but you should adapt to whatever you developement hose uses.

1. Pluriel. It is a collection of entities.
2. Oui. The atsortingbute is a representation of singular property of an entity.
3. Yes, prefix table name allows easily trackable naming of all constraints indexes and table aliases.
4. Pascal Case for table and column names, prefix + ALL caps for indexes and constraints.