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

Sur Internet, j'ai trouvé des blogs disant que cela n'ajoutait rien à la documentation et que «ça prend plus de temps pour la lire».

Questions et considérations

• Est-ce vraiment un problème? Parce que je préfixe les tables avec 'tbl' depuis mon premier emploi dans dba (le DBA principal m'a dit de le faire pour l'organisation).
• Est-ce quelque chose que 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 laissant l'autre sans, et je n'ai pas remarqué de problème de performances.

J'ai eu une fois une table et elle était brillante et belle. Il a tenu toutes les transactions financières pour une organisation. Et puis nous avons commencé à y charger des données.

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

C'est incroyable le volume de données financières générées par une société de services financiers… Ce que nous n'avions pas compris avec notre ensemble de données de test, c'est que le volume de données allait rendre leurs procédures de fin de mois intenables. Il a fallu de plus en plus de temps pour supprimer les "données du mois en cours" avant de les remplacer par le nouveau cycle d'essai.

Nous devions faire quelque chose pour accélérer le traitement sans rompre la liste non cataloguée de "qui sait quoi" qui dépend de la table MonthlyAllocation. J'ai décidé de jouer au magicien et d'extraire la nappe de dessous. Je suis allé à la vieille école et utilisé une vue partitionnée . Les données comportaient déjà un indicateur IsComplete. J'ai donc créé deux tables, chacune avec des contraintes de vérification différentes: 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é aussi sage sur le changement physique que nous avons apporté à la base de données. Aucun rapport n'a été signalé, aucun des analystes disposant d'un accès direct n'a signalé de problème avec cette "table" avant ou après.

Histoire cool frère, mais où vas-tu?

Et si ils avaient une convention de nommage ici, tbl_MonthlyAllocation? Maintenant quoi? Est-ce que nous passons de nombreuses heures de travail dans chaque ETL, chaque rapport, chaque feuille de calcul ad hoc dans l'organisation et leur mise à jour pour utiliser vw_MonthlyAllocation? Et bien sûr, tous ces changements passent par le panneau de changement, processus toujours rapide et sans douleur.

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

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

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

Les conventions de nommage sont bonnes, mais ne vous mettez pas dans une impasse.

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

La raison pour laquelle je vous dis de ne pas ajouter tbl au début de vos noms de table est la même que celle pour laquelle je dirais de ne pas ajouter child au début de votre nom. Vous ne les appelez pas enfantJohn et enfantJane. Non seulement cela n’ajoute aucune valeur, mais ils ne seront peut-être pas des enfants plus tard dans la vie et vos objets pourraient devenir des vues.

C'est un argument très subjectif, mais voici ce que je pense: le préfixe tbl est inutile.

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

Quelle valeur tbl ajoute-t-elle si ce n’est que lorsque vous consultez une liste de tables dans l’Explorateur d’objets, vous devez effectuer plus de travail pour trouver la ou les tables recherchées?

Certaines personnes disent qu'elles veulent que leur code soit clairement défini lorsqu'elles traitent d'une table ou d'une vue. Pourquoi? Et si cela est important, pourquoi ne pas nommer les vues d’une manière particulière? Dans la plupart des cas, ils agissent comme des tables, ce qui me permet de distinguer peu de choses.

C'est une pratique terrible.

tbl
tbl_
Table_
t_

... vu tous en production.

L'un des produits tbl_whateversur lequel je travaille actuellement a nommé la moitié des tables et l'autre moitié, les noms "normalement". Ils ont évidemment des développeurs qui travaillent selon des normes différentes. Une autre de leurs mauvaises habitudes est de préfixer les noms de colonnes avec des clés étrangères fk, suivis du nom de la table, fkpuis du nom de la colonne, en donnant des noms de colonne aussi terribles que fktbl_AlarmsfkAlarmsID. Cette convention de nommage n’est qu’une extension logique de tout le tbl_%mantra, et vous pouvez voir à quel point cela devient ridicule!

J'ai presque oublié l'autre base de données qui me fait pleurer quotidiennement. Les types de données préfixant les noms de colonne ... dtPaymentDate, parce que le nom avait vraiment besoin du dtpréfixe? `

ComDon't VerListen PRÉPARER AJOUTER CES ADJOINTS. proYou auxShould devrait toujours utiliser nouPrefixes et préparer vos nouNoms adjTables. proI auxHave advEven verStarted gerUtilisation de proThÉ préparatiOn en écriture normale.

COMS ADVANCED COMMENT VÉRIFICATIONS PROPRES? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

Utiliser un préfixe comme celui-ci s'appelle la notation hongroise . Son principe est simple: vous pouvez déterminer ce qui est quelque chose en nommant son nom. Ceci est particulièrement courant dans les langages de programmation, en particulier lorsque les développeurs écrivent des fonctions monolithiques qui couvrent des dizaines de pages, par manque de compétences ou par manque de fonctionnalités de langage. C'est une aide mnémonique qui aide les développeurs à conserver les types de données.

De manière générale, ce style de nommage est susceptible d’être utilisé dans un très vieux code, ou par des développeurs qui viennent d’apprendre (et qui ont appris à utiliser cette habitude), ou le font aussi longtemps qu’ils se souviennent. D'après mon expérience, il est relativement rare de voir la notation hongroise naître spontanément avec des développeurs inexpérimentés si elle n'est pas introduite dans 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 mettre dans un coin, il ne s'agit que de remplissage. La syntaxe SQL est suffisamment précise pour qu'un développeur doive toujours savoir s'il parle d'un champ, d'un enregistrement ou d'un jeu de données (qui peut être une table, une vue, etc.). Bien que cela puisse constituer un outil pédagogique précieux, 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 de la table que vous recherchez, en particulier si plusieurs thèmes de nommage différents apparaissent, tels que tbl vs. table vs. tab , etc.

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

J'ai lu quelques articles de blog comme celui - ci (il y en a plusieurs) après avoir hérité de ma première instance SQL Server et remarqué de nombreux objets avec le préfixe. Je souhaitais commencer à en développer de nouveaux avec une approche moins détaillée et une convention de dénomination singulière ( beaucoup plus facile pour moi ( et éventuellement d’autres développeurs ) de travailler sur le mappage relationnel par objet).

L’un des préfixes les plus utilisés était Tblou tbl, mais j’avais TBLet tbl_et même*TableName*_Tbl

En essayant d'interroger et de travailler à partir de Visual Studio, c'est juste l'enfer, peu importe le préfixe d'un tableau, tblmais conservez-le de cette façon pour la base de données au moins.

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

... D'autre part, je voulais juste dire que si vous prenez une autre approche et optez pour un tableau sans préfixe, nom singulier, vous rendrez un développeur heureux à l'avenir, et quoi de plus important que le bonheur?

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

1. Parfois, les objets commencent leur vie comme quelque chose mais finissent par devenir autre chose . (par exemple, la table a tblXxxété scindée en tblXxxYet tblXxxZpour 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 tbldans l'éditeur, sa fonctionnalité de saisie semi-automatique s'interrompt pendant 45 secondes, puis affiche une liste de 4 000 entrées.

Mais...

Je vais me faire l'avocat du diable et dire quelque chose que d'autres ont carrément déconseillé. Il existe 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 ERP basé sur une entité, dans lequel la logique métier est écrite en Oracle PL / SQL. Il existe depuis près de deux décennies et pourtant un système très stable (il ne s'agit pas d'un système hérité. Nous le développons en permanence).

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.

Désormais, nous souhaitons que les objets appartenant à la même entité portent le même nom mais soient néanmoins distinguables de leur objectif et de leur type. Donc, si nous avons deux entités nommées CustomerOrderet CustomerInvoice, nous aurons les objets suivants:

1. Tables pour stocker les données [ TABsuffixe]:
   • 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) [ APIsuffixe]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Générateurs de rapports; (Packages PL / SQL) [ RPIsuffixe]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Index des clés primaires [ PKsuffixe]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Index secondaires [ IXsuffixe]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(où XXXdécrit l'utilisation de l'index).
7. ... etc.

Il s’agit bien d’une forme d’ applications hongroise (notez que les mêmes types d’objets peuvent avoir des suffixes différents selon l’objet). 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 TBLet d'obtenir 4000 résultats, je peux taper Customeret obtenir tous les objets appartenant aux entités nommées Customer*.

Donc, je vous ai montré comment les métadonnées peuvent être utiles. Le but est d'avoir un ensemble d'objets de base de données liés identifiables par un nom unique, tout en les différenciant en fonction de leur objectif .

Cela dit, si vous ne disposez pas de ce type de système, il est inutile de préfixer ou de suffixer le type d'objet .

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

tl; dr Il (très probable) ajoute des informations redondantes, entraînant une surcharge cognitive, et devrait donc être supprimé.

Le contexte est une chose merveilleuse, en particulier dans les systèmes informatiques. Hors contexte, il vous est impossible de savoir si un objet appelé usersest une table, une vue, une procédure stockée ou autre chose. Les systèmes et langages hérités (ou simplement mal écrits) rendent souvent difficile la compréhension du contexte lors de la lecture du code. Par exemple, dans Bash, vous ne pouvez pas savoir ce qui se function userspasse sans au moins lire le contenu de la fonction. En Java, Map<Uid,UserDetails> users()c'est assez transparent, et vous pouvez creuser les détails facilement.

En prenant cet argument pour les tables SQL, quand serait-il utile pour les consommateurs de userssavoir s’il s’agit d’une table ou d’une vue? En d'autres termes, un tblpréfixe dira-t-il à un consommateur quelque chose qu'il ne sait pas et qu'il doit savoir?Espérons que la grande majorité des consommateurs écrira des requêtes DML et DQL à son encontre. Pour eux, il ne devrait s'agir que d'une autre source de données. Que ce soit une vue ou une table, elle doit être tout aussi pertinente que la partition, le stockage sur disque dur ou SSD, ou tout autre détail technique. Bien sûr, le DBA a 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 au profit de la minorité qui sait réellement comment naviguer dans le schéma et obtenir tous les détails techniques.

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 destinées 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 sur l'autre. L’administrateur de la base de données ou l’administrateur système ne se préoccupe que du matériel répondant aux besoins en informations. Le consommateur n'a pas besoin, ni ne devrait, être au courant de ces préoccupations.

Le client ne doit pas non plus se soucier de la construction d'un ensemble de lignes. Une table de base, une vue ou une fonction sont, à cet égard, identiques. Chacun produit simplement un ensemble de lignes et de colonnes consommées par le client. Même un simple scalaire peut être considéré comme un tableau à une ligne, à une colonne. Le modèle 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 brisée. Le client est maintenant conscient et dépend des éléments internes du serveur. Toute modification du code du serveur peut nécessiter un remaniement du client.

Je suis d’accord avec beaucoup de réponses qui disent que ce n’est pas une convention de nommage très valable. Pour les personnes qui ne sont pas convaincues par les autres réponses, je vais essayer de démontrer ce que de nombreuses autres réponses disent.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

Dans la déclaration ci-dessus, je sélectionne trois colonnes sur un nom dbo.foo. L'une des principales plaintes des préfixeurs est qu'ils ne savent pas s'il dbo.foos'agit d'une table ou d'une vue. Bien sûr, c’est l’un des points forts d’une vue comme une 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, il ressemblerait à ceci.

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

Je soupçonne que ce commentaire semble moins utile, bien que ce soit ce que les préfixeurs plaident efficacement. Pour mettre en évidence le bruit inutile que ce commentaire de métadonnées injecte, considérons une requête plus complexe.

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;

Est-ce que les commentaires supplémentaires rendent cette requête plus facile à raisonner ou ajoutent-ils simplement du bruit supplémentaire? À mon avis, ils ajoutent simplement du bruit et une valeur zéro. C'est ce que les anti-préfixeurs essaient de dire. En outre, l’utilisation de préfixes est bien pire que ces commentaires, car le coût de la mise à jour d’un commentaire est beaucoup moins élevé que celui 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 transmettent pas d'informations précieuses, ils doivent être évités.

Certaines personnes citent un autre avantage des préfixes, à savoir qu’ils peuvent conférer une sorte de regroupement ou d’ordre dans votre environnement de développement. Comme nous passons beaucoup de temps à éditer du code, cela peut être un argument séduisant pour certains. Cependant, selon mon expérience, les environnements de développement modernes offrent des options équivalentes ou supérieures qui ne répandent pas votre code avec des métadonnées inutiles et limitent votre flexibilité.

Joe Celko , expert américain en bases de données SQL et relationnelles, a couvert ce sujet à maintes reprises . J'ai personnellement été l'un des destinataires de son discours sur Internet (il se sent honoré), et il parle de ces préfixes comme "tibbling", ou plus précisément décrits comme " skeuomorphism ".

L’idée générale est que ces préfixes sont une pratique de codage ancienne (probablement en raison de limitations de nommage, comme une limite de 8 octets pour les noms d’objet), transmise à des générations de programmeurs sans raison apparente utile, à part cela 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 restent, même si la raison pour laquelle elles ont été utilisées à l'origine est maintenant obsolète. "Tibbling" est l’un des exemples les plus connus de la gestion de bases de données relationnelles.

Pour finir, cela n’ajoute aucune valeur, mais ajoute exactement 4 octets d’espace de stockage sur chaque nom de table sans autre motif que celui-ci. Il n'offre rien aux systèmes SQL Server modernes, mais si vous vous sentez mieux de l'avoir là-bas, utilisez-le.

Ma suggestion serait que vous cessiez de le faire immédiatement. Si cela vous met mal à l'aise, ajoutez "_tbl" à la fin du nom de votre table. Bien sûr, pour les raisons déjà mentionnées, nul besoin de le faire. La personne qui vous a initialement demandé de le faire vous a donné de mauvais conseils. C’était peut-être mauvais "cela a du sens compte tenu du système mal configuré de notre organisation", mais dans ce cas, c’était à lui de remédier. Encore mauvais conseil.

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

En ce qui concerne 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 je le fais sur d'autres objets tels que des vues, des procédures stockées, des fonctions, etc.

Je dois dire s'il vous plaît arrêtez de faire ça. C'est arrivé dans le passé, mais en continuant de 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 je fouille une base de données pour un article spécifique, et que je ne suis pas le seul à ouvrir l'explorateur d'objets et que je pense que je vais y accéder, vous savez que c'est alphabétique. Jusqu'à ce que les préfixes commencent à brouiller les cartes, et que j'ai tblname, tbl_name, tbname, t_name et mille autres variantes, il devient très difficile de trouver cette table que vous savez déjà être une table

De même, si vous préfixez 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 savoir, utilisez plutôt un suffixe. NameOfMyView_v, NameOfMyProc_sp. beaucoup plus facile de rechercher visuellement

Mais que se passe-t-il si vous parcourez une procédure stockée depuis longtemps et que vous ne pouvez pas dire facilement en quoi consiste une vue processus ou table? De toute façon, il y a de bonnes chances que ces lettres soient aliasées, 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à cadrées, n'hésitez pas à mettre en place votre propre système 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, mais seulement de le rendre plus

Si je dois penser à l’avantage d’avoir le préfixe 'tbl', c’est que dans SSMS actuel, avec intellisense, je peux simplement taper

select * from tbl

puis trouvez le nom de la table dont j'ai besoin (en supposant que je n’ai aucune idée du nom exact de la table). C'est un travail en une étape. Bien sûr, nous pouvons toujours trouver le nom de la table par des étapes supplémentaires, mais je dirais que avec préfixe « TBL », c'est le ONE travail étape, et c'est la raison pour laquelle je préfère toujours un préfixe (pas nécessairement « TBL ») dans mon propre projet de devoirs.

Edit : (Après tant de votes négatifs, je pense toujours qu’il est intéressant de souligner quelques avantages de niche de donner un préfixe spécifique à une catégorie spécifique d’objets dans le serveur SQL). Il semble que personne ne se plaint d'avoir un préfixe pour les procédures / fonctions / vues stockées, mais il y a toujours des arguments à propos de le faire avec des tables. (Pour moi, dans le monde réel, je ne me soucie pas de savoir si nous donnons un préfixe ou non aux tableaux).

Je me souviens que dans SQL Server 2005 jours, il était nécessaire de trouver les tables utilisées dans lesquelles les procédures / vues stockées, avec les noms de table préfixés, était un travail si facile avec Regular Expression / C #. (Oui, je sais qu'il y avait d'autres moyens, aucun argument ici).

Ma carrière progresse avec la lecture de nombreux articles / articles sur les "meilleures pratiques", mais j'ai également constaté suffisamment d'exceptions à presque toutes les "meilleures pratiques" d'une manière ou d'une autre dans des scénarios différents. Ainsi, je me dis toujours, à moi-même et à mes collègues administrateurs de bases de données, de porter un jugement en fonction des besoins de l'entreprise. La "meilleure pratique" a bien sa place, mais elle ne peut être envisagée que dans le contexte de notre propre environnement.

Considérez dbo.Uservs dbo.tUser. Maintenant, imaginez que vous souhaitiez trouver tous les endroits dans le code où cette table est utilisée. Quelle version rend cela plus facile (ou même possible?) Le mot "utilisateur" est susceptible de contenir beaucoup de faux positifs, tels que des noms de variables, des commentaires, etc.

C'est quelque chose que je n'ai vu dans aucune des réponses, mais je suis un développeur avec DBA, alors peut-être que d'autres n'ont pas eu à travailler sur du code hérité, où les requêtes peuvent être intégrées à l'application, et pas toutes. les requêtes qualifient pleinement les références avec le schéma, et ainsi de suite. (Même si tout est pleinement qualifié, vous devez trouver dbo.Useret [dbo].[User]et dbo.[User]et cetera). Ou des versions de base de données où les "informations de dépendance" deviennent obsolètes et inexactes (par exemple, les anciennes versions de MS-SQL)

Ainsi, sur certains projets sur lesquels j'ai travaillé et qui sont mixtes, j'ai demandé un préfixe tou v(préfixe tbl_ devient ridicule), simplement pour en faire un terme de recherche plus sélectif.

Dans les projets ultérieurs, tels que Outils de données SQL Server (hello, Rechercher toutes les références) et l'accès à la base de données exclusivement par le biais d'une couche ORM, il n'y a pas d'utilitaire, car la recherche de toutes les utilisations de la table est triviale (comme le renommer!).

Chaque côté a ses avantages et ses inconvénients. Il appartient au responsable de votre équipe ou de votre entreprise de décider des conventions à suivre.

Pour notre part, nous utilisons la tblconvention. La raison principale est que nous savons dans les scripts ce que nous pouvons et ne devons pas faire. Nous avons des projets variés et des personnes qui ne connaissent pas le schéma par cœur. Nos tables ont des noms logiques, il est donc facile de s'y retrouver lors de l'écriture de scripts. Ce faisant, lorsque nous trouvons une table, nous savons immédiatement (via IntelliSense) que c'est une table. On peut affirmer que l'ajout du préfixe n'ajoute pas beaucoup de contexte. Cependant, le supprimer signifie qu’il n’ya pas de contexte.

Le seul avantage réel de ne pas utiliser le préfixe est l'interchangeabilité. Cependant, je dirais que c'est une situation potentiellement dangereuse. Bien sûr, vos scripts et vos requêtes ne casseront pas, mais peut-être que vous commencez à trop vous fier à ce fait, alors que certaines choses ne fonctionnent pas avec les vues ou sont mal avisées.

En fin de compte, tout se résume à ce que votre équipe préfère et à la façon dont elle écrit le code / les scripts.

J'avais l'habitude d'avoir une raison pour préfixer les noms de table avec "tbl". Si vous consultez une liste d'objets de base de données, vous pouvez exécuter cette requête:

select * from sysobjects

Si vous voulez obtenir uniquement des tables, vous pouvez faire ceci:

select * from sysobjects where type = 'U'

Qui peut s'en souvenir? Si vos noms de table commencent tous par "tbl", vous pouvez utiliser cette requête qui ne vous oblige pas à mémoriser les valeurs de la colonne type:

select * from sysobjects where name like 'tbl%'

Comme vous avez balisé SQL Server 2014, cela ne vous concerne pas car, à partir de SQL Server 2005, vous pouvez le faire à la place:

select * from sys.tables

Je ne peux pas penser à une autre raison de préfixer les noms de table.