Perché il prefisso dei nomi delle colonne è considerato una cattiva pratica?

Secondo un popolare post SO è considerato una cattiva pratica il prefisso dei nomi delle tabelle. Nella mia azienda ogni colonna è preceduta da un nome di tabella. Per me è difficile da leggere. Non sono sicuro del motivo, ma questa denominazione è in realtà lo standard dell'azienda. Non sopporto la convenzione di denominazione, ma non ho documentazione per sostenere il mio ragionamento.

Tutto quello che so è che leggere AdventureWorks è molto più semplice. In questo DB della nostra azienda vedrai una tabella, Persona e potrebbe avere il nome della colonna:

Person_First_Name
o forse anche
Person_Person_First_Name (non chiedermi perché vedi la persona 2x)

Perché è considerata una cattiva pratica pre-correggere i nomi delle colonne? I trattini bassi sono considerati malvagi anche in SQL?

I caratteri di sottolineatura non sono cattivi, ma sono più difficili da scrivere. Ciò che è male è cambiare gli standard a metà flusso senza riparare tutti gli oggetti esistenti. Ora hai personId, Person_id, ecc. E non ricordi quale tabella utilizza i caratteri di sottolineatura o meno. La coerenza nella denominazione (anche se personalmente non ti piacciono i nomi) aiuta a semplificare la codifica.

Personalmente, l'unico posto in cui sento la necessità di utilizzare il tablename in una colonna è nella colonna ID (l'uso di solo ID è un antipattern nella progettazione del database come possono dirti tutti coloro che hanno fatto query di report estese. È così divertente rinominare 12 colonne nella tua query ogni volta che scrivi un rapporto). Ciò semplifica anche la conoscenza immediata degli FK in altre tabelle poiché hanno lo stesso nome.

Tuttavia, in un database maturo, è più lavoro di quanto valga la pena cambiare uno standard esistente. Basta accettare che è lo standard e andare avanti, ci sono cose molto più critiche che devono essere risolte per prime.

Un argomento per il prefisso del nome della colonna impedirebbe le "collisioni" di nomi quando si uniscono più tabelle E quando il creatore della query non utilizza gli alias.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Entrambe le query avrebbero due colonne "name" ( name_1, name_2 ) senza "dire" a quale entità appartiene. E non puoi mai essere sicuro dei nomi delle colonne generate (sarà name_2 o name_3 o ...). Se usi il prefisso del nome della tabella, i nomi delle colonne sarebbero person_name , company_name in modo da conoscere ogni nome a cui appartiene l'entità, oltre a sapere che i nomi delle colonne rimarranno costanti (se li stai ottenendo in Java usando JDBC per esempio ).

Entrambi gli argomenti possono essere ignorati se si utilizza l'aliasing, ma penso che la maggior parte delle convenzioni di codifica applicate nelle aziende derivino da molti programmatori (junior) che non seguono le buone pratiche. In questo caso, ad esempio, l'utilizzo del carattere jolly su un'istruzione SELECT può causare problemi senza il prefisso del nome.

Per quanto riguarda il carattere di sottolineatura nei nomi di tabelle e colonne, lo uso ampiamente perché utilizzo solo caratteri minuscoli e carattere di sottolineatura come separatore. L'uso di solo lettere minuscole aiuta a distinguere gli identificatori dalle parole chiave SQL (che scrivo in tutte le lettere maiuscole):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

L'aggiunta di questo tipo di prefissi ai nomi delle colonne renderà più difficile l'evoluzione di una tabella. Ad esempio: se alla fine ti rendi conto che vuoi / devi cambiare il nome della tabella, dovrai modificare l'intera struttura della tabella (vale a dire, non solo il nome della tabella, ma il nome di tutte le sue colonne). Ciò renderebbe anche più difficile l'aggiornamento degli indici della tabella e il codice dei client che lo interrogano.

Ci sono eccezioni se usate con giudizio (secondo la risposta di Patrick Karcher sul tuo link) per nomi di colonne comuni (normalmente solo ID, a volte Nome) che sarebbero ambigui troppo spesso .

Un'altra procedura consigliata consiste nel qualificare sempre colonne e oggetti nelle query. Quindi i prefissi di colonna diventano discutibili e ingombrano il tuo codice.

Confronta questi: qual è il più facile per gli occhi?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

In generale, non sembrano esserci standard onnipresenti. La domanda a cui hai collegato ha diverse risposte molto votate con convenzioni totalmente diverse. Ovviamente, ognuno difenderà i propri standard ed è molto più importante mantenere convenzioni coerenti in un progetto.

Detto questo, il prefisso dei nomi delle colonne sembra essere eccessivo. Sai già con quale tabella stai lavorando e una situazione con due colonne di diverse tabelle con lo stesso nome può essere facilmente risolta usando gli alias di tabella o colonna.

In TSQL è possibile fare riferimento ai campi nel formato TableName.FieldName se si desidera evitare l'ambiguità, quindi l'aggiunta di nomi di tabelle ai nomi di campi in realtà toglie la leggibilità rendendola TableName.TableName_FieldName o simile. Penso che usare il trattino basso o meno sia più una scelta personale. Preferisco CamelCase e utilizzo _ quando voglio aggiungere un suffisso o simile, ad esempio TableName_Temp, ma sono solo io.

Una volta ho lavorato su un sistema in cui abbiamo deciso di utilizzare i codici brevi per aggiungere il prefisso alle colonne. I campi PK utilizzavano il "nome della tabella completa" come prefisso e tutte le altre colonne utilizzavano costantemente 2-4 caratteri come prefisso. Ogni colonna utilizzava anche un dominio di dati come suffisso. Se fatto in modo coerente, può essere molto bello e pulito. Non ha senso che uno standard di denominazione di un tipo o un altro implichi una codifica sciatta. La presenza di uno standard coerente è ciò che è importante. Ho visto un certo numero di database incoerenti perché non esiste uno standard chiaro e che più di ogni altra cosa mi indicherebbe che potrebbero esserci problemi nelle strutture di dati. Se il progettista di un database non riesce nemmeno a nominare in modo coerente gli oggetti e i loro figli,

Il prefisso è una cattiva pratica perché causa il problema che è stato progettato per prevenire. Come hai affermato, è molto difficile leggere colonne con prefisso. Se si finiscono con nomi di colonne duplicati in una query in cui si uniscono due tabelle, è possibile risolverle o è una vista, una procedura memorizzata o una funzione definita dall'utente tabulare che lo fa per te se ti ritrovi a unire costantemente determinate tabelle.

Per quanto riguarda l'uso sottolineato in un nome di tabella, questo è un argomento religioso. Alla fine, se aumenta la visibilità e rende le cose più facili, provaci. In genere non avrei mai spazi o tabelle in una colonna o in un nome di tabella. Tuttavia, potrei fare un'eccezione per le tabelle o le viste utilizzate solo da un pacchetto di report o esportate in un file CSV.

Molti database hanno limiti severi sul numero di caratteri in un nome di colonna (cioè Oracle).

Se si lavora con un database che consente nomi di colonne lunghi, ma in seguito si decide di voler migrare quella struttura su un altro sistema di database, i prefissi aumentano le possibilità che i nomi delle colonne non siano validi.

Sebbene tu stia lavorando con SQL Server ora, nessuno può prevedere il futuro ed è possibile che in futuro il tuo software debba funzionare su più database.

Prendi in considerazione la possibilità di scrivere un dizionario di dati (o "registro"). Con questo intendo un documento contenente tutti gli elementi di dati nel tuo modello: nome, descrizione, ecc. Dovrebbe essere indipendente dall'implementazione del modello, ad esempio non dovrebbe menzionare i nomi delle tabelle. Come disambiveresti nomi come 'ID', 'Tipo' e 'Codice'?

Un approccio è quello di seguire le linee guida dello standard internazionale ISO / IEC 11179 - dopo tutto, perché reinventare la ruota? La struttura di base è:

[Object] [Qualifier] Property RepresentationTerm

con delimitatori tra gli elementi: SQL non gioca bene con gli spazi nei nomi delle colonne e il trattino basso funziona bene visivamente.

Ho la sensazione che qualcuno nella tua organizzazione stesse cercando di seguire queste linee guida quando hanno inventato nomi di elementi come Person_Person_First_Name.

L'esempio che mi piace mostrare è il dizionario dei dati del servizio sanitario nazionale (NHS) del Regno Unito .

Quindi non penso che la convenzione di denominazione con cui devi lavorare suoni troppo male.

Nell'implementazione, ad esempio in SQL, ad alcune persone piace omettere gli elementi secondari Oggetto, Qualificatore e Proprietà quando il nome della tabella fornisce il contesto, ad esempio person_first_namediventa first_namenella Persontabella ecc. Tuttavia, la regola empirica che un elemento di dati non dovrebbe cambiare semplicemente il suo nome a causa della sua posizione nel modello fisico sembra buona. Chiunque pensi che non sia una buona idea seguire questa regola dovrebbe avere il compito di documentare tutte le varianti di nome che hanno usato :)

Troverai un bel riassunto di ISO 11179 nel libro Stile di programmazione di Joe Celko , comprese le prove per preferire i trattini bassi come delimitatori nei nomi delle colonne.

Alcuni trovano più facile nel codice sapere da quale tabella provengono i dati, tuttavia, se stai parlando di un sistema orientato agli oggetti, dovresti usare il contesto del nome per sapere da dove proviene, in questo caso il nome della tabella.

Personalmente, il prefisso del nome della tabella è un'indicazione che gli sviluppatori non sono molto qualificati e mentre scavi più in profondità troverai molte altre convenzioni di codifica errate e se dovessi indovinare l'app ha troppe tabelle, è buggy, ecc.