•  08-07-2019
  •  | 
  •  

Question

Comme je suis sûr que beaucoup de gens ont des standards différents, j'ai fait de ce post un wiki de communauté.

Ma question est la suivante: quel est le bon schéma de nommage pour les alias de table? J'utilise la première lettre de chaque mot du nom de la table, mais cela devient tout à fait illisible. Voici un exemple rapide. 

FROM incidents i
FROM cause_attack ca
FROM obscure_table ot

Merci.

Était-ce utile?

La solution

Le but d'un alias est de raccourcir le nom afin de ne pas avoir besoin de verbosité.

Il doit seulement être unique dans une requête donnée, il n'est donc pas nécessaire de définir un schéma pour les nommer.

Éditer: De plus, les alias que vous utiliseriez dépendent fortement du schéma de nommage de la table. Si toutes vos tables ont un nom en 5 parties où les 4 premières sont communes dans une requête, il est idiot de conserver ces parties dans les alias.

Autres conseils

Les noms de tables eux-mêmes devraient déjà être lisibles. Par conséquent, si vous voulez un nom lisible, évitez simplement d’alias.

Cela signifie que le but d'un alias est autant d'empêcher vos pauvres doigts de retaper de longs noms que n'importe quoi d'autre. Dans ce cas, les noms abrégés fonctionnent bien, d’autant plus qu’ils doivent être déclarés juste à côté du nom complet.

Les seules exceptions à cette règle concernent les jonctions multiples d'une table. Dans ce cas, vous avez besoin d'un élément pour identifier l'instance de la table dont vous avez besoin, ou si vous crénelez une sous-requête.

Habituellement, j'essaie de suivre la structure de nommage des tables.

J'essaie d'utiliser des noms de table parlante, tels que 'RelObjectProperty' , et les alias de manière cohérente, comme (pour cet exemple) 'rop' : 

SELECT
  p.Name    PropertyName,
  o.Name    ObjectName,
  rop.Value PropertyValue
FROM
  Property p
  INNER JOIN RelObjectProperty rop ON rop.PropertyId = p.Id
  INNER JOIN Object              o ON rop.ObjectId   = o.Id
WHERE
  o.Id = 10

Ce schéma d'acronymes est utile pour une base de données avec des noms de table stricts et sans collision, mais cela ne peut pas toujours être garanti.

Il pourrait y avoir une table 'RelObjectPresentation' , auquel cas je casserais probablement le schéma et utiliserais 'rop' pour le premier et 'ropr ' pour ce dernier. Même dans ce cas, je serais cohérent en termes d’incohérence et utiliserais au moins l’alias 'ropr' partout , et pas seulement dans les requêtes nécessitant une distinction entre et . 'rop' .

Je fais généralement la même chose que vous, sauf que je n'utilise que la première lettre, en majuscule, jusqu'à ce que plusieurs tables commencent par le même nom, ou plusieurs références à la même table, puis j'ajoute un suffixe pour distinguer les deux ... N'importe quoi pour que ce soit clair pour le lecteur. Si j'utilise la même table dans une sous-requête (par exemple, la table Employee) que dans la requête externe, je peux utiliser un préfixe i ou o pour distinguer, comme dans 

-- Find Highest paid Emplyees in Each Division ..... 
Select * From Employee oE -- For outer Employee table
Where Salary = (Select Max(Salary) 
                From Employee iE
                Where DivisionId = oE.DivisionId)

Ainsi, lorsque je lis le code SQL, je peux lire les alias en interne comme suit: "Employé interne". ou " Employé externe "

Dans un scénario de stockage de données, j'utilise généralement les premiers caractères, mais préfixez soit fait _ , dim _ ou cdim _ afin de distinguer les faits , dimension ou tables de dimensions conformes. Je ferai aussi lkup _ pour les recherches (donc LOOKUP_TRANSACTION_TYPE deviendra lkup_TT ).

La technique de recherche fonctionnerait également dans les bases de données de type OLTP.

En règle générale, les requêtes dans lesquelles les abréviations sont difficiles à suivre ne contiennent pas énormément de tables et il n'y a généralement pas de conflit entre les alias de tables (car il existe souvent déjà des groupements tels que SYSTEM_SUBSYSTEM_ENTITY_TYPE ), le nom de la table a donc toujours le même alias.

C’est un bon avantage par rapport à la technique A, B, C ou T1, T2, T3, car elle est suivable et permet d’éviter les erreurs de copier-coller.

Bien que je ne sois pas du genre Oracle (en fait, cette question devrait s'appliquer à presque tous les SGBDR), mon réponse à" Quelle était la règle de codage standard la plus étrange que vous étiez obligé de suivre " semble bien s'appliquer ici (modifié avoir un sens dans le contexte de cet article) ...

Pour nous, tout dépend du nom de la table. Nous avons eu cette idée d'un client chez qui nous travaillions qui utilisait cette norme, et après nous y être tous adaptés, nous avons adoré. Les noms de table sont assez verbeux, mais en raison de leur préfixe mnémonique unique, nous avons toujours eu un ensemble d'alias normalisé: utilisez simplement le préfixe. Une fois que nous nous sommes désengagés de ce client, nous avons conservé le schéma de nommage des nouveaux systèmes. Depuis, il connaît un franc succès.

Voici le schéma: chaque table est nommée en majuscule, avec des soulignés entre les mots. Chaque table a un préfixe (généralement 1 à 6 caractères) qui est généralement un acronyme ou une abréviation du nom de la table principale. Chaque champ de la table était également précédé du même préfixe. Les préfixes sont également utilisés, dans les requêtes complexes, comme alias. Donc, disons que vous avez un schéma simple où les gens peuvent posséder des chats ou des chiens. Cela ressemblerait à ceci: 

PER_PERSON
    PER_ID
    PER_NameFirst
    PER_NameLast
    ...
CAT_CAT
    CAT_ID
    CAT_Name
    CAT_Breed
    ...
DOG_DOG
    DOG_ID
    DOG_Name
    DOG_Breed
    ...
PERCD_PERSON_CAT_DOG (for the join data)
    PERCD_ID
    PERCD_PER_ID
    PERCD_CAT_ID
    PERCD_DOG_ID

Encore une fois, les préfixes sont là pour rappeler les mots "recommandé" et "recommandé". (et forcé!) alias de table lors de la création de jointures. Le préfixe a facilité la rédaction de la majorité des requêtes de jointure, car il était très rare de devoir explicitement référencer une table avant le champ, car même les noms de champs associés sont préfixés et donc déjà quelque peu ciblés sur le nom.

Un effet secondaire intéressant est que vos développeurs pourront éventuellement commencer à faire référence à des tables de conversation sans plus que le préfixe. Un goût acquis, bien sûr ... Mais cela fonctionne pour nous.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top