Sto guardando alcuni video di Brent Ozar ( come questo, per esempio ) e mi suggerisce di non aggiungere prefissi alle tabelle con ‘tbl’o ‘TBL’.

Su Internet ho trovato alcuni blog che dicevano che non aggiunge nulla alla documentazione e che "ci vuole più tempo per leggerlo".

Domande e considerazioni

• È davvero un problema? Perché sto anteponendo le tabelle a "tbl" dal mio primo lavoro dba (il DBA senior mi ha detto di farlo per l'organizzazione).
• È qualcosa di cui devo liberarmi? Ho fatto alcuni test, copiando un tavolo davvero grande e dandogli il prefisso 'tbl', mantenendo l'altro senza di esso, e non ho notato alcun problema di prestazioni.

Una volta avevo un tavolo ed era lucido e bello. Ha tenuto tutte le transazioni finanziarie per un'organizzazione. E poi abbiamo iniziato a caricare i dati al suo interno.

Nel mese in corso, possono indicare e riformulare i valori tutte le volte che vogliono. Negli ultimi 10 giorni di un mese, avrebbero rideterminato i numeri -> eseguendo l'elaborazione ETL -> esaminando i rapporti più volte al giorno. Una volta completato il mese, i libri vengono sigillati e non possono modificare i valori.

È incredibile quanti dati finanziari generano un'azienda di servizi finanziari ... Qualcosa che non ci siamo resi conto con il nostro set di dati di test era il volume di dati che avrebbe reso insostenibili le loro procedure di fine mese. Ci è voluto un tempo sempre più lungo per eliminare i "dati del mese corrente" prima di sostituirli con la nuova corsa di prova.

Abbiamo dovuto fare qualcosa per renderlo più veloce per l'elaborazione senza rompere l'elenco non catalogato di "chissà cosa" che dipende tutto dalla tabella MonthlyAllocation. Ho deciso di fare il mago e tirare fuori la tovaglia da sotto di loro. Sono andato alla vecchia scuola e ho usato una vista partizionata . I dati avevano già un flag IsComplete, quindi ho creato due tabelle, ognuna con vincoli di controllo contrario: MonthlyAllocationComplete, MonthlyAllocationInComplete

Ho quindi creato la vista partizionata con lo stesso nome della tabella originale: MonthlyAllocation. Nessun processo è stato più saggio riguardo alle modifiche fisiche apportate al database. Nessuna segnalazione interrotta, nessuno degli analisti con accesso diretto ha segnalato problemi con quella "tabella" prima o dopo.

Bella storia fratello, ma dove stai andando?

E se avessero avuto una convenzione di denominazione lì, tbl_MonthlyAllocation? E adesso? Dedichiamo molte ore uomo a esaminare ogni ETL, ogni rapporto, ogni foglio di calcolo ad hoc nell'organizzazione e aggiornarli per utilizzare vw_MonthlyAllocation? E poi ovviamente tutti quei cambiamenti passano attraverso la Change Board e questo è sempre un processo rapido e indolore.

Il tuo capo potrebbe chiederti: qual è il premio per l'azienda che lavora di nuovo?

L'altra opzione diventa lasciare questa vista denominata tbl_ e non passare tutto il tempo a testare, aggiornare e distribuire il codice. Che diventa un aneddoto divertente che spieghi a tutti i nuovi assunti ea quelli con scarsa attenzione, che devono lavorare con il database sul motivo per cui non sei coerente con la denominazione degli oggetti

Oppure non codificare due volte gli oggetti con metadati ridondanti. Il database ti dirà felicemente cos'è una tabella, cos'è una vista, cos'è una funzione con valori di tabella, ecc.

Le convenzioni di denominazione sono buone, ma non dipingerti in un angolo con loro.

Brent qui (il ragazzo a cui ti riferisci nella domanda).

Il motivo per cui ti dico di non aggiungere tbl nella parte anteriore dei nomi di tabella è lo stesso motivo per cui direi di non aggiungere un bambino nella parte anteriore del nome di tuo figlio. Non li chiami figlio John e figlio Jane. Non solo non aggiunge alcun valore, ma potrebbe non essere un bambino più avanti nella vita - e i tuoi oggetti potrebbero in seguito diventare viste.

Questo è un argomento molto soggettivo, ma ecco la mia opinione: il prefisso tbl è inutile.

Quanti scenari stai osservando il codice e non riesci a capire se qualcosa è una tabella o qualcos'altro?

Quale valore aggiunge tbl tranne che quando si guarda un elenco di tabelle in Esplora oggetti, è necessario fare più lavoro per trovare quello / i che si sta cercando?

Alcune persone dicono che vogliono che sia chiaro nel loro codice quando hanno a che fare con una tabella o una vista. Perché? E se questo è importante, perché non solo dare un nome alle visualizzazioni in modo speciale? Nella maggior parte dei casi, si comportano proprio come tabelle, quindi vedo poco valore nel distinguere.

È una pratica terribile.

tbl
tbl_
Table_
t_

... li ho visti tutti in produzione.

Uno dei prodotti con cui sto attualmente lavorando ha la metà dei tavoli denominati tbl_whatevere l'altra metà denominata "normalmente" - Ovviamente hanno sviluppatori che lavorano a standard diversi. Un'altra delle loro cattive abitudini è il prefisso dei nomi delle colonne che sono chiavi esterne con fk, seguito dal nome della tabella, fkquindi dal nome della colonna, dando nomi di colonne terribili come fktbl_AlarmsfkAlarmsID. Quella convenzione di denominazione è solo un'estensione logica dell'intero tbl_%mantra e puoi vedere quanto sia ridicolo!

Mi ero quasi dimenticato dell'altro database che mi fa piangere su base giornaliera. Tipi di dati che precedono i nomi delle colonne ... dtPaymentDate, perché il nome aveva davvero bisogno del dtprefisso? `

comDon't verListen prepTo ad aggiustare Quelli che regolano Altre persone. proYou auxDovrebbe sempre VerUse nouPrefixes prepWith proYour Nomi adattabili. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

comVedi advCome proIli effettivi effettivi? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

L'uso di un prefisso come questo è noto come notazione ungherese . La sua premessa è semplice: puoi determinare cosa è qualcosa in base al nome. Ciò è particolarmente comune nei linguaggi di programmazione, specialmente quando gli sviluppatori scrivono funzioni monolitiche che coprono decine di pagine, sia per mancanza di abilità che per mancanza di funzionalità linguistiche. È un aiuto mnemonico che aiuta gli sviluppatori a mantenere dritti i tipi di dati.

In generale, è probabile che questo stile di denominazione venga utilizzato in codice molto vecchio o da sviluppatori che stanno solo imparando (e si è capitato di imparare questa abitudine), o lo stanno facendo da quando possono ricordare. Nella mia esperienza, ho osservato che è relativamente raro vedere la notazione ungherese spuntare spontaneamente con sviluppatori inesperti se non vengono introdotti da un corso di programmazione o tutorial; è più probabile che utilizzino nomi di variabili come i o x o acct .

Oltre a dipingerti in un angolo, questo è davvero solo un riempitivo. La sintassi SQL è abbastanza precisa che uno sviluppatore dovrebbe sempre sapere se si tratta di un campo, record o set di dati (che può essere una tabella, una vista, ecc.). Sebbene possa essere di grande aiuto didattico, questa sintassi di solito non dovrebbe esistere nei database di produzione. Può danneggiare la leggibilità e rendere più difficile trovare la tabella che stai cercando, specialmente se compaiono diversi temi di denominazione alternativi, come tbl vs. tabella vs. tab , ecc.

Al database non importa davvero come si chiamano tabelle, campi, ecc. Sono solo byte di dati che sono organizzati in un ordine particolare dai loro operatori umani o script. Tuttavia, gli umani che devono conservare questi dati apprezzeranno i nomi significativi, come "utente", "ordine" e "account". È anche più pratico se si utilizzano query SQL, come "mostra tabella come 'a%'". L'uso di prefissi e suffissi può complicare inutilmente la manutenzione altrimenti banale.

Ho letto alcuni post di blog come questo o questo (ce ne sono molti) dopo aver ereditato la mia prima istanza di SQL Server e notato molti oggetti con prefisso, volevo iniziare a svilupparne di nuovi con un approccio meno dettagliato e una singolare convenzione di denominazione ( molto più facile per me [ e possibilmente altri sviluppatori ] lavorare sulla mappatura relazionale degli oggetti).

Uno dei prefissi più utilizzati era Tblo tbl, ma poi ho avuto TBLed tbl_e perfino*TableName*_Tbl

Nel provare a interrogare e lavorare con Visual Studio questo è semplicemente un inferno, non mi dispiacerebbe avere un intero set di tabelle con prefisso, tblma per favore continuate a farlo in questo modo per l'intero Database, almeno.

Quindi alla fine direi che è una questione di preferenze personali, ma ha anche molto a che fare con la coerenza e se segui questa strada, molte persone saranno felici almeno di mantenerlo lo stesso lungo il tuo sviluppo.

... D'altra parte, volevo solo dire, se segui un approccio diverso e scegli una tabella con nomi singoli non prefissi, renderai felice uno sviluppatore in futuro, e cosa c'è di più importante della felicità?

Sì, l'aggiunta di un prefisso che indica il tipo di oggetto è un problema e non è necessario . Perché,

1. A volte gli oggetti iniziano la vita come qualcosa ma finiscono per diventare qualcos'altro . (ad esempio, la tabella è tblXxxstata suddivisa in tblXxxYe tblXxxZper qualche motivo e sostituita con una vista che unisce le due nuove tabelle. Ora hai una vista chiamata tblXxx).
2. Quando si digita tbll'editor, la sua funzione di completamento automatico si blocca per 45 secondi e quindi mostra un elenco di 4000 voci.

Ma...

Interpreterò l'avvocato del diavolo e dirò qualcosa contro cui altri hanno decisamente sconsigliato. Ci sono alcuni rari casi in cui un suffisso / prefisso potrebbe essere utile, ed ecco un esempio dell'organizzazione per cui lavoro.

Abbiamo un sistema ERP basato su entità, in cui la logica aziendale è scritta in Oracle PL / SQL. Ha quasi vent'anni, ma è un sistema molto stabile (questo non è un sistema legacy. Lo stiamo continuamente sviluppando).

Il sistema è basato sull'entità e ogni entità associa una tabella, più viste, più pacchetti PL / SQL e un host di altri oggetti di database.

Ora, vogliamo che gli oggetti appartenenti alla stessa entità abbiano lo stesso nome ma siano comunque distinguibili per scopo e tipo. Quindi, se abbiamo due entità che sono nominate CustomerOrdere CustomerInvoice, avremo i seguenti oggetti:

1. Tabelle per memorizzare i dati [ TABsuffisso]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Viste utilizzate dai client [Nessun suffisso]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Interfaccia per operazioni di base; (Pacchetti PL / SQL) [ APIsuffisso]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Generatori di report; (Pacchetti PL / SQL) [ RPIsuffisso]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Indici per chiavi primarie [ PKsuffisso]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Indici secondari [ IXsuffisso]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(dove XXXdescrive l'utilizzo dell'indice).
7. ... e così via.

Questa è davvero una forma di app ungherese (si noti che lo stesso tipo di oggetti può avere suffissi diversi a seconda dello scopo). Ma, con un suffisso anziché un prefisso. Non posso dirti abbastanza su come questo sistema sia così facile da leggere. IntelliSense funziona davvero perché invece di digitare TBLe ottenere 4000 risultati, posso digitare Customere ottenere tutti gli oggetti appartenenti alle entità denominate Customer*.

Quindi, qui ti ho mostrato come i metadati possono essere utili. Lo scopo è di avere un set correlato di oggetti di database identificabili con un singolo nome, ma differenziarli in base al loro scopo .

Detto questo, se non si dispone di questo tipo di sistema, non è possibile utilizzare il prefisso o il suffisso del tipo di oggetto .

Si noti che non abbiamo usato suffissi come _table, _packageo _view(cioè il tipo dell'oggetto). Ad esempio, sia (3) che (4) sono pacchetti PL / SQL, ma usano un suffisso diverso. È lo stesso per (5) e (6), entrambi gli indici. Quindi il suffisso si basa sullo scopo piuttosto che sul tipo .

tl; dr It (molto probabilmente) aggiunge informazioni ridondanti, portando a sovraccarico cognitivo e dovrebbe quindi essere rimosso.

Il contesto è una cosa meravigliosa, specialmente nei sistemi informatici. Fuori dal contesto, non è possibile stabilire se qualcosa chiamato userssia una tabella, una vista, una procedura memorizzata o qualcos'altro. I sistemi e le lingue legacy (o solo scritte male) spesso rendono difficile elaborare il contesto durante la lettura del codice. Ad esempio, in Bash, non puoi dire cosa function usersfa senza almeno leggere il contenuto della funzione. In Java, Map<Uid,UserDetails> users()è abbastanza trasparente e puoi scavare facilmente nei dettagli.

Prendendo questo argomento nelle tabelle SQL, quando sarebbe utile per i consumatori userssapere se si tratta di una tabella o di una vista? In altre parole, un tblprefisso dirà a qualcuno dei consumatori qualcosa che non sanno e che devono sapere?Speriamo che la stragrande maggioranza dei consumatori scriverà query DML e DQL contro di essa. Per loro dovrebbe essere solo un'altra fonte di dati e se si tratta di una vista o di una tabella dovrebbe essere altrettanto rilevante che sia partizionato, archiviato su HDD o SSD o qualsiasi altro dettaglio tecnico. Il DBA ovviamente deve conoscere questi dettagli per eseguire alcune rare query DDL / DCL, ma sembra controproducente inquinare lo spazio dei nomi per il bene della minoranza che sa davvero come navigare nello schema e ottenere tutti i dettagli tecnici.

Una delle caratteristiche di un sistema di gestione di database relazionali è che separa la presentazione logica delle informazioni ai client dalla memoria fisica. Il primo è colonne in un set di righe. Quest'ultimo è come file su un volume di archiviazione. È compito del DBMS mappare l'uno all'altro. È un problema solo per il DBA o l'amministratore di sistema quale hardware supporta la necessità di informazioni. Il consumatore non deve, anzi, non essere consapevole di tali preoccupazioni.

Né il cliente dovrebbe preoccuparsi di come viene costruito un set di righe. Una tabella di base, una vista o una funzione sono tutti, a questo proposito, identici. Ognuno produce semplicemente un insieme di righe e colonne consumate dal client. Anche un semplice scalare può essere considerato una tabella a una riga, a una colonna. Il modello di riga / colonna è il contratto tra il client e il server.

Con il prefisso dei nomi degli artefatti con il loro tipo di implementazione questa separazione delle preoccupazioni viene interrotta. Il client è ora a conoscenza e dipendente dagli interni del server. La modifica della codifica del server potrebbe richiedere una rielaborazione del client.

Ci sono molte risposte qui con cui sono d'accordo che ti dicono che questa non è una convenzione di denominazione molto preziosa. Per quelle persone che non sono convinte dalle altre risposte, proverò a dimostrare ciò che dicono molte altre risposte.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

Nell'affermazione sopra sto selezionando tre colonne da qualcosa chiamato dbo.foo. Una delle lamentele principali dei prefissi è che non sanno se dbo.fooè una tabella o una vista. Naturalmente questo è uno dei punti di forza di una visione come un'astrazione, ma sto divagando. Dicono che dovremmo prefissare l'oggetto in questo modo dbo.tblFoo. Ora possono vedere che l'oggetto è una tabella (probabilmente) nella query sopra. Tuttavia, se scrivessimo l'equivalente funzionale di quell'obiettivo sarebbe simile a questo.

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

Ho il sospetto che il commento sembri poco utile, anche se questo è ciò che i prefissi stanno effettivamente sostenendo. Per evidenziare il rumore inutile che questo commento di metadati inietta considera una query più complicata.

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;

I commenti extra rendono più facile ragionare su questa query o aggiungono solo ulteriore rumore? Secondo me aggiungono solo rumore extra e aggiungono valore zero. Questo è ciò che gli anti prefissi stanno cercando di dire. Inoltre, l'utilizzo dei prefissi è effettivamente peggiore di tali commenti poiché il costo dell'aggiornamento di un commento è molto inferiore rispetto all'aggiornamento del nome di una tabella con prefisso se il modello di dati deve essere adattato. Dato che questi prefissi hanno un costo e non forniscono informazioni preziose, dovrebbero essere evitati.

Un altro vantaggio dei prefissi che alcune persone citano è che può impartire una sorta di raggruppamento o ordinamento nel proprio ambiente di sviluppo. Dato che dedichiamo molto tempo alla modifica del codice, questo può essere un argomento seducente per alcuni. Tuttavia, nella mia esperienza, i moderni ambienti di sviluppo offrono opzioni equivalenti o superiori che non sporcano il tuo codice di metadati inutili e limitano la tua flessibilità.

Questo è stato trattato molte volte, ma probabilmente il più famoso da Joe Celko , un esperto americano di database relazionale e SQL. Sono stato personalmente sul lato ricevente di una delle sue invenzioni online (mi sono sentito onorato), e parla di questi prefissi come "brontolio", o più precisamente descritto come " scettuomorfismo ".

L'idea generale è che questi prefissi sono una pratica di codifica di molto tempo fa (probabilmente a causa di limitazioni di denominazione, come un limite di 8 byte per i nomi degli oggetti), tramandata generazioni di programmatori senza motivo apparentemente utile, a parte il fatto che è solo "il modo è fatta".

Aziende, blogger e programmatori trasmettono informazioni con il loro stile di codifica e alcuni stili potrebbero essere un po 'più "Frankenstein" di altri. Una società potrebbe avere uno "stile di casa" e il programmatore è costretto a imparare questa pratica.

Nel tempo le cose si attaccano, anche se il motivo per cui sono state utilizzate originariamente è ora deprecato. "Tibbling" è uno degli esempi più noti di questo nella gestione di database relazionali.

Per concludere: non aggiunge alcun valore, aggiunge esattamente 4 byte di spazio di archiviazione su ciascun nome di tabella per nessun motivo se non perché è lì. Non offre nulla ai moderni sistemi SQL Server, ma se ti fa sentire meglio averlo lì, vai avanti e usalo.

Il mio suggerimento sarebbe di smettere di farlo immediatamente. Se questo ti mette a disagio in futuro, aggiungi "_tbl" alla fine dei nomi delle tabelle. Naturalmente per le ragioni già menzionate, non è nemmeno necessario farlo. La persona che inizialmente ti ha detto di farlo ti ha dato dei cattivi consigli. Potrebbe essere stato male "questo ha senso in termini di consulenza del sistema mal organizzato" della nostra organizzazione, ma in quel caso era suo compito ripararlo. Ancora un cattivo consiglio.

"Non aggiungere prefissi alle tue tabelle con tbl" è davvero un problema?

Per quanto riguarda il sistema? No. Per quanto riguarda le altre persone? Può essere. Puoi generare un sacco di odio.

Personalmente non faccio prefisso tabelle ma lo faccio su altri oggetti come viste, stored procedure, funzioni, ecc.

Devo dire che per favore smetti di farlo. È successo in passato, ma continuando a farlo incoraggi nuove persone che vengono nel tuo ambiente a pensare che si tratti di una convenzione locale e continui. Ma non continueranno semplicemente, lo faranno in modo leggermente diverso

Quando si trascina un db per un oggetto specifico, e non sono l'unico che aprirà esploratore di oggetti e penserò solo che lo farò scorrere, sai che è alfabetico. Questo fino a quando i prefissi iniziano a confondere le acque, e ho tblname, tbl_name, tbname, t_name e mille altre varianti, diventa davvero difficile trovare quella tabella che sai che è già una tabella

Allo stesso modo anteponendo a tutto vw_ o sp_, entrerà qualcuno e otterrai SPname, spname, s_p_name. Rimuovi tutti i prefissi, il software sa quale sia l'elemento, se devi davvero saperlo, usa invece un suffisso. NameOfMyView_v, NameOfMyProc_sp. molto più facile da cercare visivamente

Ma cosa succede se si sta trascinando un proc a lungo memorizzato e non si può facilmente dire che cosa è una vista un proc o una tabella? Bene, è probabile che questi saranno alias comunque, e anche se non il suffisso viene in tuo soccorso

Non aver paura di cambiare quello che fai, e se entri in un ambiente in cui le convenzioni di denominazione sono già state messe a punto, non aver paura di implementare le tue e iniziare a cambiare le cose in meglio. Abbinando il caos esistente non c'è possibilità di renderlo meno confuso, rendendolo solo più moreso

Se devo pensare a un vantaggio di avere il prefisso 'tbl', è che nell'attuale SSMS, con intellisense, posso semplicemente digitare

select * from tbl

e quindi trova il nome della tabella di cui ho bisogno (supponendo che non abbia idea del nome esatto della tabella). Questo è un lavoro in un solo passaggio. Ovviamente, possiamo sempre scoprire il nome della tabella attraverso passaggi aggiuntivi, ma direi che con il prefisso 'tbl', questo è il lavoro ONE step, ed è per questo che preferisco sempre un prefisso (non necessariamente 'tbl') in il mio progetto di compiti a casa.

Modifica : (Dopo così tanti voti negativi, penso ancora che valga la pena sottolineare alcuni vantaggi di nicchia di dare un prefisso specifico a una specifica categoria di oggetti nel server SQL). Sembra che nessuno si lamenti di avere un prefisso per stored procedure / funzioni / viste, ma c'è sempre argomento su come farlo con le tabelle. (Per me, nel mondo reale non me ne può fregare di meno se diamo un prefisso o meno alle tabelle).

Ricordo che nei giorni SQL Server 2005, c'era un requisito per trovare quali tabelle venivano utilizzate in quali stored procedure / viste, con i nomi delle tabelle con il prefisso, era un lavoro così facile con Regular Expression / C #. (Sì, so che c'erano altri modi, nessuna discussione qui).

La mia carriera cresce con la lettura di molti articoli / articoli sulle "migliori pratiche", ma ho anche visto abbastanza eccezioni a quasi ogni "migliore pratica" in un modo o nell'altro in diversi scenari. Pertanto, dico sempre a me stesso e ai miei colleghi DBA di esprimere un giudizio in base ai requisiti aziendali, la "migliore pratica" ha sicuramente il suo posto, ma può essere considerata solo nel contesto del nostro ambiente.

Considerare dbo.Uservs dbo.tUser. Ora immagina di voler trovare tutti i posti nel codice in cui viene utilizzata questa tabella. Quale versione rende questo più semplice (o addirittura possibile?) È probabile che la parola "utente" abbia molti falsi positivi, come nomi di variabili, commenti, ecc.

Questo è qualcosa che non ho visto in nessuna delle altre risposte, ma sono uno sviluppatore-cum-DBA, quindi forse altri non hanno dovuto lavorare su codice legacy, dove le query possono essere incorporate nell'applicazione e non tutte le query qualificano pienamente i riferimenti con lo schema e cose del genere. (Anche se tutto è pienamente qualificato, è necessario trovare dbo.Usere [dbo].[User]ed dbo.[User]e così via). O versioni di database in cui le "informazioni sulla dipendenza" diventano obsolete e non sono accurate (ad es. Versioni precedenti di MS-SQL)

Quindi, su alcuni progetti su cui ho lavorato, che sono mescolati in questo modo, ho richiesto un to un vprefisso (tbl_ diventa sciocco), semplicemente per renderlo un termine di ricerca più selettivo.

Nei progetti successivi, con cose come SQL Server Data Tools (ciao, Trova tutti i riferimenti) e l'accesso al database esclusivamente tramite un livello ORM, non esiste alcuna utilità, perché trovare tutti gli usi della tabella è banale (come lo sta rinominando!)

Ogni parte ha i suoi vantaggi e i suoi svantaggi. Sta solo alla guida del tuo team o della tua compagnia decidere le convenzioni da seguire.

Per uno, usiamo la tblconvenzione. Il motivo principale è che negli script sappiamo cosa possiamo e non dovremmo fare. Abbiamo vari progetti e persone che saltano nel non conoscere a memoria lo schema. Le nostre tabelle hanno nomi logici, quindi è facile trovare la strada mentre scrivi gli script. Nel fare ciò, quando troviamo un tavolo, sappiamo immediatamente (tramite IntelliSense) che è un tavolo. Si può sostenere che l'aggiunta del prefisso non aggiunge molto contesto. Tuttavia, rimuoverlo significa che non c'è contesto.

L'unico vero vantaggio di non usare il prefisso è l'intercambiabilità. Tuttavia, direi che questa è una situazione potenzialmente pericolosa. Certo, i tuoi script e le tue domande non si romperanno, ma forse inizi a fare troppo affidamento su questo fatto, mentre alcune cose semplicemente non funzionano con le viste o sono sconsiderate.

Alla fine si riduce davvero a ciò che il tuo team preferisce e al modo in cui scrive codice / script.

Avevo un motivo per aggiungere il prefisso ai nomi delle tabelle con "tbl". Se stai guardando un elenco di oggetti di database, potresti eseguire questa query:

select * from sysobjects

Se vuoi ottenere solo tabelle, puoi farlo:

select * from sysobjects where type = 'U'

Chi se lo ricorda? Se i nomi delle tue tabelle iniziano tutti con "tbl", puoi utilizzare questa query che non richiede di memorizzare i valori della colonna type:

select * from sysobjects where name like 'tbl%'

Poiché hai taggato SQL Server 2014, questo non si applica a te perché a partire da SQL Server 2005, puoi invece farlo:

select * from sys.tables

Non riesco a pensare a un altro motivo per aggiungere il prefisso ai nomi delle tabelle.