L'ajout du préfixe «tbl» aux noms de table est-il vraiment un problème?

Question

Je regarde des vidéos de Brent Ozar ( comme celle-ci, par exemple ) et il suggère de ne pas préfixer les tableaux avec ‘tbl’ ou ‘TBL’.

Sur Internet, j'ai trouvé des blogs disant que cela n'ajoute rien à la documentation, et aussi que "cela prend plus de temps à le lire".

Questions et considérations

• Est-ce vraiment un problème? Parce que je préfixe les tables avec 'tbl' depuis mon premier emploi dba (le DBA senior m'a dit de le faire pour l'organisation ).
• Est-ce quelque chose dont je dois me débarrasser? J'ai fait quelques tests, en copiant une très grande table et en lui donnant le préfixe 'tbl', tout en gardant l'autre sans elle, et je n'ai remarqué aucun problème de performance.

Answer 1

Une fois, j'avais une table et elle était brillante et belle. Il détenait toutes les transactions financières d'une organisation. Et puis nous avons commencé à y charger des données.

Au cours du mois en cours, ils peuvent énoncer et reformuler les valeurs aussi souvent qu'ils le souhaitent. Au cours des 10 derniers jours d'un mois, ils reformulent les chiffres -> exécutent le traitement ETL -> examinent les rapports plusieurs fois par jour. Une fois le mois terminé, les livres sont scellés et ils ne peuvent pas modifier les valeurs.

C'est incroyable la quantité de données financières qu'une entreprise de services financiers génère ... Ce que nous n'avions pas réalisé avec notre ensemble de données de test, c'était le volume de données qui rendrait intenables leurs procédures de fin de mois. Il a fallu de plus en plus de temps pour supprimer les "données du mois en cours" avant de les remplacer par la nouvelle version d'essai.

Nous avons dû faire quelque chose pour accélérer le traitement sans rompre la liste non cataloguée de "qui sait quoi", tout dépend de la table MonthlyAllocation. J'ai décidé de jouer au magicien et de fouetter la nappe en dessous. Je suis allé à la vieille école et utilisé un vue partitionnée . Les données avaient déjà un indicateur IsComplete, j'ai donc créé deux tables, chacune avec des contraintes de vérification contraires: MonthlyAllocationComplete, MonthlyAllocationInComplete

J'ai ensuite créé la vue partitionnée avec le même nom que la table d'origine: MonthlyAllocation. Aucun processus n'a été plus sage quant aux modifications physiques que nous avons apportées à la base de données. Aucun rapport n'a éclaté, aucun des analystes ayant un accès direct n'a signalé de problème avec cette "table" avant ou après.

Cool story bro, mais où allez-vous?

Et s'ils avaient là une convention de dénomination, tbl_MonthlyAllocation? Maintenant quoi? Passons-nous beaucoup d'heures de travail à parcourir chaque ETL, chaque rapport, chaque feuille de calcul ad hoc dans l'organisation et à les mettre à jour pour utiliser vw_MonthlyAllocation? Et puis bien sûr, tous ces changements passent par le tableau des changements et c'est toujours un processus rapide et indolore.

Votre patron pourrait demander: Quelle est la récompense pour l'entreprise pour tout ce travail?

L'autre option consiste à laisser cette vue nommée tbl_ et à ne pas passer tout ce temps à tester, mettre à jour et déployer le code. Ce qui devient une anecdote amusante que vous expliquez à toutes les nouvelles recrues, et à celles qui ont une courte durée d'attention, qui doivent travailler avec la base de données pour expliquer pourquoi vous n'êtes pas cohérent avec la dénomination des objets

Ou vous ne doublez pas d'encodage d'objets avec des métadonnées redondantes. La base de données vous indiquera avec plaisir ce qu'est une table, ce qu'est une vue, ce qu'est une fonction de valeur de table, etc.

Les conventions de dénomination sont bonnes, mais ne vous peignez pas dans un coin avec elles.

Answer 2

Brent ici (le gars dont vous parlez dans la question).

La raison pour laquelle je vous dis de ne pas ajouter de tbl au début du nom de votre table est la même raison pour laquelle je dirais de ne pas ajouter d'enfant au début du nom de votre enfant. Vous ne les appelez pas childJohn et childJane. Non seulement cela n'ajoute aucune valeur, ils peuvent ne pas être un enfant plus tard dans la vie - et vos objets peuvent plus tard devenir des vues.

Answer 3

C'est un argument très subjectif, mais voici mon point de vue: le préfixe tbl est inutile.

Combien de scénarios examinez-vous le code et vous ne pouvez pas dire si quelque chose est une table ou autre chose?

Quelle valeur ajoute tbl, sauf que lorsque vous regardez une liste de tables dans l'Explorateur d'objets, vous devez faire plus de travail pour trouver celle (s) que vous recherchez?

Certaines personnes disent qu'elles souhaitent que cela soit clair dans leur code lorsqu'elles traitent d'une table ou d'une vue. Pourquoi? Et si c'est important, pourquoi ne pas seulement nommer vues d'une manière spéciale? Dans la plupart des cas, ils agissent comme des tableaux, donc je vois peu de valeur à distinguer.

Answer 4

C'est une terrible pratique.

tbl
tbl_
Table_
t_

... les a tous vus en production.

L'un des produits avec lesquels je travaille actuellement a la moitié des tables nommées tbl_whatever, et l'autre moitié nommée "normalement" - Ils ont évidemment des développeurs qui travaillent selon des normes différentes. Une autre de leurs mauvaises habitudes consiste à préfixer les noms de colonnes qui sont des clés étrangères avec fk, suivi du nom de la table, fk puis du nom de la colonne, donnant des noms de colonnes horribles tels que fktbl_AlarmsfkAlarmsID. Cette convention de dénomination n'est qu'une extension logique de l'ensemble tbl_% mantra, et vous pouvez voir à quel point ça devient ridicule!

J'ai presque oublié l'autre base de données qui me fait pleurer au quotidien. Types de données préfixant les noms de colonnes ... dtPaymentDate, parce que le nom avait vraiment besoin du préfixe dt? `

Answer 5

n'ÉCOUTEZ PAS PRÉPARER À AJUSTER CES AUTRES PERSONNES. proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

cONSULTEZ COMMENT LES VÉRIFICATIONS DE PROTÈGE ADÉQUATE? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

Answer 6

L'utilisation d'un préfixe comme celui-ci est connue sous le nom de notation hongroise . Sa prémisse est simple: vous pouvez déterminer ce que quelque chose est par son nom. Cela est particulièrement courant dans les langages de programmation, en particulier lorsque les développeurs écrivent des fonctions monolithiques qui s'étendent sur des dizaines de pages, soit par manque de compétence, soit par manque de fonctionnalités de langage. C'est une aide mnémonique qui aide les développeurs à garder les types de données droits.

De manière générale, ce style de dénomination est susceptible d'être utilisé dans un code très ancien, ou par des développeurs qui sont en train d'apprendre (et qui ont appris cette habitude), ou qui le font depuis aussi longtemps qu'ils s'en souviennent. D'après mon expérience, j'ai observé qu'il est relativement rare de voir la notation hongroise surgir spontanément avec des développeurs inexpérimentés s'ils ne leur sont pas présentés par un cours de programmation ou un tutoriel; ils sont plus susceptibles d'utiliser des noms de variables comme i ou x ou acct .

En plus de vous peindre dans un coin, ce n'est vraiment que du remplissage. La syntaxe SQL est suffisamment précise pour qu'un développeur sache toujours s'il s'agit d'un champ, d'un enregistrement ou d'un ensemble de données (qui peut être une table, une vue, etc.). Bien qu'elle puisse être un excellent outil pédagogique, cette syntaxe ne devrait généralement pas exister dans les bases de données de production. Cela peut nuire à la lisibilité et rendre plus difficile la recherche du tableau que vous recherchez, surtout si plusieurs thèmes de dénomination alternatifs apparaissent, comme tbl vs . tableau vs onglet , etc.

La base de données ne se soucie pas vraiment de ce que vous appelez vos tables, champs, etc. Ce ne sont que des octets de données qui sont organisés dans un ordre particulier par leurs opérateurs ou scripts humains. Cependant, les humains qui doivent conserver ces données apprécieront les noms significatifs, comme "utilisateur", "commande" et "compte". C'est aussi plus pratique si vous utilisez des requêtes SQL, comme "afficher la table comme 'a%'". L'utilisation de préfixes et de suffixes peut compliquer inutilement une maintenance autrement triviale.

Answer 7

J'ai lu quelques articles de blog comme this ou this (il y en a pas mal) après avoir hérité de ma première instance SQL Server et remarqué que de nombreux objets étaient préfixés, je voulais commencer à en développer de nouveaux avec une approche moins verbeuse et une convention de dénomination singulière (beaucoup plus facile pour moi de [ et éventuellement d'autres développeurs ] travailler sur le mappage relationnel objet).

L'un des préfixes les plus utilisés était Tbl ou tbl, mais j'avais ensuite TBL et tbl_ et même *TableName*_Tbl

En essayant d'interroger et de travailler à partir de Visual Studio, c'est vraiment l'enfer, je n'aurais pas d'importance d'avoir un ensemble complet de table préfixé tbl mais s'il vous plaît, gardez-le de cette façon pour l'ensemble de la base de données, au moins.

Donc, à la fin, je dirais certainement que c'est une question de préférence personnelle, mais cela a aussi beaucoup à voir avec la cohérence et si vous suivez cette voie, beaucoup de gens seront heureux au moins que vous gardiez la même chose tout au long de votre développement.

... D'un autre côté, je voulais juste dire que si vous adoptez une autre approche et optez pour une table non-préfixe, au nom singulier, vous rendrez un développeur heureux à l'avenir, et quoi de plus important que le bonheur?

Answer 8

Oui, l'ajout d'un préfixe qui indique le type de l'objet est un problème, et inutile . Parce que,

1. Parfois, les objets commencent la vie comme quelque chose mais vont finissent par devenir autre chose . (par exemple, la table tblXxx a été divisée en tblXxxY et tblXxxZ pour une raison quelconque et remplacée par une vue qui joint les deux nouvelles tables. Vous avez maintenant une vue appelée tblXxx).
2. Lorsque vous tapez tbl dans l'éditeur, sa fonction de saisie semi-automatique se bloque pendant 45 secondes, puis affiche une liste de 4000 entrées.

Mais...

Je vais jouer l'avocat du diable et dire quelque chose que les autres ont carrément déconseillé. Il y a quelques rares cas où un suffixe/préfixe pourrait être utile, et voici un exemple de l'organisation pour laquelle je travaille.

Nous avons un système basé sur ERP, où la logique métier est écrite en Oracle PL/SQL. Il a près de deux décennies, mais un système très stable (Ce n'est pas un système hérité. Nous sommes développement continu).

Le système est basé sur une entité et chaque entité associe une table, plusieurs vues, plusieurs packages PL/SQL et un hôte d'autres objets de base de données.

Maintenant, nous voulons que les objets appartenant à la même entité aient le même nom mais puissent être distingués de leur but et de leur type. Donc, si nous avons deux entités nommées CustomerOrder et CustomerInvoice, nous aurons les objets suivants:

1. Tables pour stocker les données [TAB suffixe]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Vues utilisées par les clients [Pas de suffixe]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Interface pour les opérations de base; (Packages PL/SQL) [API suffixe]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Générateurs de rapports; (Packages PL/SQL) [RPI suffixe]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Index des clés primaires [PK suffixe]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Index secondaires [IX suffixe]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX (où XXX décrit l'utilisation de l'index).
7. ... etc.

Il s'agit en effet d'une forme de applications hongroises (notez que les mêmes type objets peuvent avoir différents suffixes selon le but). Mais, avec un suffixe au lieu d'un préfixe. Je ne peux pas vous dire assez comment ce système est si facile à lire. IntelliSense fonctionne réellement parce qu'au lieu de taper TBL et d'obtenir 4000 résultats, je peux taper Customer et obtenir tous les objets appartenant aux entités nommées Customer*.

Donc, ici, je vous ai montré comment les métadonnées peuvent être utiles. Le but est d'avoir un ensemble connexe d'objets de base de données identifiables par un seul nom, mais de les différencier en fonction de leur objectif .

Cela dit, si vous n'avez pas ce type de système, il n'est pas utile de préfixer ou de suffixer le type de l'objet .

Notez que nous n'avons pas utilisé de suffixes comme _table, _package, ou _view (c'est-à-dire le type de l'objet). Par exemple, (3) et (4) sont des packages PL/SQL, mais utilisez un suffixe différent. C'est la même chose pour (5) et (6), qui sont tous deux des index. Le suffixe est donc basé sur but plutôt que sur type.

Answer 9

tl; dr Il ajoute (très probablement) des informations redondantes, conduisant à des frais généraux cognitifs, et doit donc être supprimé.

Context est une chose merveilleuse, surtout dans les systèmes informatiques. Hors contexte, vous ne pouvez pas dire si quelque chose appelé users est une table, une vue, une procédure stockée ou autre chose. Les systèmes et langages hérités (ou tout simplement mal écrits) rendent souvent difficile l'élaboration du contexte lors de la lecture du code. Par exemple, dans Bash, vous ne pouvez pas dire ce que function users Fait sans au moins lire le contenu de la fonction. En Java, Map<Uid,UserDetails> users() est assez transparent, et vous pouvez creuser jusqu'aux détails facilement.

En prenant cet argument dans les tables SQL, quand serait-il utile pour les consommateurs de users de savoir s'il s'agit d'une table ou d'une vue? En d'autres termes, est un préfixe tbl qui va dire à n'importe quel consommateur quelque chose qu'ils ne connaissent pas et ont besoin savoir? Espérons que la grande majorité des consommateurs écriront des requêtes DML et DQL contre elle. Pour eux, cela devrait être juste une autre source de données, et qu'il s'agisse d'une vue ou d'une table, elle devrait être à peu près aussi pertinente que si elle est partitionnée, stockée sur le disque dur ou le SSD, ou tout autre détail technique. Le DBA a bien sûr besoin de connaître ces détails pour exécuter de rares requêtes DDL/DCL, mais il semble contre-productif de polluer l'espace de noms pour le bien de la minorité qui sait vraiment comment naviguer dans le schéma et obtenir tous les détails techniques.

Answer 10

L'une des caractéristiques d'un système de gestion de base de données relationnelle est qu'il sépare la présentation logique des informations aux clients du stockage physique. Le premier est des colonnes dans un ensemble de lignes. Ce dernier est sous forme de fichiers sur un volume de stockage. C'est le travail du SGBD de mapper l'un à l'autre. Le DBA ou l'administrateur système ne concerne que le matériel qui prend en charge le besoin d'informations. Le consommateur n'a pas besoin, et ne doit pas en effet, être conscient de ces préoccupations.

Le client ne doit pas non plus se préoccuper de la construction d'un ensemble de lignes. Une table de base, une vue ou une fonction sont toutes, à cet égard, identiques. Chacun produit simplement un ensemble de lignes et de colonnes que le client consomme. Même un simple scalaire peut être considéré comme un tableau à une ligne et à une colonne. Le modèle de ligne/colonne est le contrat entre le client et le serveur.

En préfixant les noms des artefacts avec leur type d'implémentation, cette séparation des préoccupations est rompue. Le client est désormais conscient et dépend des éléments internes du serveur. La modification du codage du serveur peut nécessiter un retravail client.

Answer 11

Il y a beaucoup de réponses ici avec lesquelles je suis d'accord qui vous disent que ce n'est pas une convention de dénomination très précieuse. Pour les personnes qui ne sont pas convaincues par les autres réponses, je vais essayer de démontrer ce que beaucoup d'autres réponses disent.

---

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

Dans la déclaration ci-dessus, je sélectionne trois colonnes parmi quelque chose nommé dbo.foo. L'une des principales plaintes des préfixeurs est qu'ils ne savent pas si dbo.foo est une table ou une vue. Bien sûr, c'est l'un des points forts d'une vue en tant qu'abstraction, mais je m'éloigne du sujet. Ils disent que nous devrions préfixer l'objet comme ceci dbo.tblFoo. Maintenant, ils peuvent voir que l'objet est une table (probablement) dans la requête ci-dessus. Cependant, si nous écrivons l'équivalent fonctionnel de cet objectif, cela ressemblerait à ceci.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

Je soupçonne que ce commentaire semble moins qu'utile même si c'est ce que les préfixes plaident effectivement. Pour mettre en évidence le bruit inutile que ce commentaire de métadonnées injecte, considérez une requête plus compliquée.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

Les commentaires supplémentaires facilitent-ils la réflexion ou ajoutent-ils simplement du bruit supplémentaire? À mon avis, ils ajoutent simplement du bruit supplémentaire et ajoutent une valeur nulle. C'est ce que les anti-préfixes essaient de dire. De plus, l'utilisation de préfixes est en fait pire que ces commentaires car le coût de mise à jour d'un commentaire est beaucoup plus faible que la mise à jour du nom d'une table préfixée si votre modèle de données doit être adapté. Étant donné que ces préfixes ont un coût et qu'ils ne communiquent pas d'informations précieuses, ils doivent être évités.

Un autre avantage des préfixes que certaines personnes citent est qu'il peut conférer une sorte de regroupement ou de classement dans votre environnement de développement. Puisque nous passons beaucoup de temps à éditer le code, cela peut être un argument séduisant pour certains. Cependant, d'après mon expérience, les environnements de développement modernes offrent des options équivalentes ou supérieures qui ne jonchent pas votre code de métadonnées inutiles et limitent votre flexibilité.

Answer 12

Cela a été couvert à plusieurs reprises, mais probablement le plus célèbre par Joe Celko , un expert américain en SQL et en bases de données relationnelles. J'ai personnellement été à la réception de l'une de ses diatribes en ligne (je me suis senti honoré), et il parle de ces préfixes comme de "tibbling", ou plus précisément décrit comme " skeuomorphism ".

L'idée générale est que ces préfixes sont une pratique de codage d'il y a longtemps (probablement en raison de limitations de nommage, comme une limite de 8 octets aux noms d'objet), transmis à des générations de programmeurs sans raison apparemment utile, à part que c'est juste "la voie c'est fait".

Les entreprises, les blogueurs et les programmeurs transmettent des informations avec leur propre style de codage, et certains styles peuvent être un peu plus "Frankenstein" que d'autres. Une entreprise peut avoir un "style maison" et le programmeur est obligé d'apprendre cette pratique.

Au fil du temps, les choses persistent, même si la raison pour laquelle elles ont été utilisées à l'origine est désormais obsolète. "Tibbling" en est l'un des exemples les plus connus dans la gestion de bases de données relationnelles.

Pour arrondir: il n'ajoute aucune valeur, il ajoute exactement 4 octets d'espace de stockage sur chaque nom de table sans autre raison que parce qu'il est là. Il n'offre rien aux systèmes SQL Server modernes, mais si cela vous fait vous sentir mieux de l'avoir, allez-y et utilisez-le.

Answer 13

Ma suggestion serait que vous arrêtiez de faire cela immédiatement. Si cela vous met mal à l'aise à l'avenir, ajoutez "_tbl" au fin de vos noms de table. Bien sûr, pour les raisons déjà mentionnées, il n'est pas nécessaire de le faire non plus. La personne qui vous a initialement dit de le faire vous a donné de mauvais conseils. C'était peut-être mauvais "cela a du sens en termes de conseils sur le système mal configuré de notre organisation", mais dans ce cas, c'était son travail de le réparer. Encore de mauvais conseils.

Answer 14

"Ne préfixez pas vos tables avec tbl" est-il vraiment un problème?

Concernant le système? Non. Concernant les autres? Peut être. Vous pouvez générer beaucoup de haine.

Personnellement, je ne préfixe pas les tables mais le fais sur d'autres objets comme les vues, les procédures stockées, les fonctions, etc.

Answer 15

Je dois dire s'il vous plaît, arrêtez de faire ça. C'est arrivé dans le passé, mais en continuant à le faire, vous encouragez les nouvelles personnes qui viennent dans votre environnement à penser que c'est une convention locale et à continuer. Mais ils ne continueront pas, ils le feront légèrement différemment

Lorsque vous parcourez une base de données pour un élément spécifique, et je ne suis pas le seul à ouvrir l'Explorateur d'objets et à penser que je vais y faire défiler, vous savez que c'est alphabétique. C'est jusqu'à ce que les préfixes commencent à brouiller les eaux, et j'ai tblname, tbl_name, tbname, t_name et mille autres variations, il devient vraiment difficile de trouver cette table dont vous savez qu'elle est déjà une table

De même en préfixant tout vw_ ou sp_, quelqu'un entrera et vous obtiendrez SPname, spname, s_p_name. Supprimez tous les préfixes, le logiciel sait ce qu'est l'élément, si vous avez vraiment besoin de le savoir, utilisez plutôt un suffixe. NameOfMyView_v, NameOfMyProc_sp. beaucoup plus facile à rechercher visuellement

Mais que se passe-t-il si vous parcourez un processus stocké depuis longtemps et que vous ne pouvez pas facilement déterminer ce qu'est un affichage ou un tableau? Eh bien, il est probable que ceux-ci seront alias de toute façon, et même si ce n'est pas le suffixe qui vient à votre secours

N'ayez pas peur de changer ce que vous faites, et si vous entrez dans un environnement où les conventions de dénomination sont déjà vouées à l'échec, n'ayez pas peur d'implémenter les vôtres et commencez à changer les choses pour le mieux. En faisant correspondre le chaos existant, il n'y a aucune chance de le rendre moins déroutant, seulement de le rendre plus compliqué