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

I caratteri di sottolineatura non sono malvagi, ma solo più difficile da digitare. Ciò che è male sta cambiando gli standard midstream senza correggere tutti gli oggetti esistenti. Ora hai personId, Person_id, ecc. E non riesco a ricordare quale tabella usi i trattini bassi o meno. La coerenza nella denominazione (anche se personalmente non ti piacciono i nomi) aiuta a semplificare il codice.

Personalmente, l'unico posto in cui sento il bisogno di usare il tablename in una colonna è nella colonna ID (l'uso di ID giusto è un antipattern nella progettazione del database, come chiunque altro abbia fatto query di rapporto estese in grado di dirlo. divertente rinominare 12 colonne nella query ogni volta che si scrive un report.) Ciò rende anche più facile conoscere immediatamente gli FK nelle altre tabelle poiché hanno lo stesso nome.

Tuttavia, in un database maturo, è più lavoro di quanto valga la pena cambiare uno standard esistente. Accetto solo che è lo standard e vai avanti, ci sono molte più cose critiche che devono essere risolte prima.

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

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

SELECT * FROM person JOIN company ON ...

Entrambe le query avrebbero due colonne "nome" ( nome_1, nome_2 ) senza "dire" a quale entità appartiene. E non puoi mai essere sicuro dei nomi delle colonne generate (sarà nome_2 o nome_3 o ...). Se si utilizza il prefisso del nome della tabella, i nomi delle colonne sarebbero nome_personale , nome_azienda in modo da conoscere ogni nome a quale entità appartiene, oltre a sapere che i nomi delle colonne rimarranno costante (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 avvengano come conseguenza di molti (junior) programmatori 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.

Come per il carattere di sottolineatura nei nomi di tabelle e colonne, lo uso estensivamente perché uso solo il carattere minuscolo e il carattere di sottolineatura come separatore. Usare solo lettere minuscole aiuta a distinguere gli identificatori dalle parole chiave SQL (che digito in maiuscolo):

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à una tabella più difficile da evolvere. Ad esempio: se alla fine ti rendi conto che vuoi / devi cambiare il nome della tabella, dovrai modificare l'intera struttura della tabella (ad esempio, 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 ne fanno richiesta.

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

Un'altra best practice consiste nel qualificare sempre colonne e oggetti nelle query. Quindi i prefissi delle colonne diventano discutibili e ingombrano il codice.

Confronta questi: che è 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 ti sei collegato ha diverse risposte votate dall'alto con convenzioni totalmente diverse. Naturalmente, 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. Conoscerai già la tabella su cui stai lavorando e una situazione con due colonne di tabelle diverse con lo stesso nome può essere facilmente risolta utilizzando 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 dei campi in realtà elimina la leggibilità, rendendola TableName.TableName_FieldName o simile. Penso che usare underscore o meno sia più una scelta personale. Preferisco CamelCase e io uso _ quando voglio aggiungere un suffisso o simile, ad es. TableName_Temp, ma sono solo io.

Una volta ho lavorato su un sistema in cui abbiamo deciso di utilizzare i codici funzione per il prefisso delle colonne. I campi PK utilizzavano il "nome della tabella completa" come prefisso e tutte le altre colonne utilizzavano in modo coerente da 2 a 4 caratteri come prefisso. Ogni colonna utilizzava anche un dominio dei dati come suffisso. Se fatto costantemente, può essere molto bello e pulito. Non ha senso che uno standard di denominazione di un tipo o di un altro implichi una codifica scadente. La presenza di uno standard coerente è ciò che è importante. Ho visto un numero di database che sono incoerenti perché non esiste uno standard chiaro e che più di ogni altra cosa mi indicherebbe che potrebbero esserci problemi nelle strutture dati. Se il progettista di un database non può nemmeno dare un nome coerente agli oggetti e ai loro figli, perché questo mi porterebbe a credere che ci sia qualcosa di coerente o riflessivo sul modello di dati, le relazioni, i vincoli, l'integrità, ecc. Sottostanti?

Il prefisso è una cattiva pratica perché causa la prevenzione del problema. Come hai affermato, è molto difficile leggere le colonne con prefisso. Se si finisce con nomi di colonne duplicati in una query in cui si uniscono due tabelle, è possibile risolverli, oppure è una vista, una stored procedure o una funzione definita dall'utente tabulare che lo fa per te se ti trovi costantemente unito a tabelle particolari.

Per quanto riguarda l'uso di underscored in un nome di tabella, è un argomento religioso. Alla fine se aumenta la visibilità e facilita le cose. In genere non avrei mai spazi o tabelle in un nome di colonna o tabella. Tuttavia, potrei fare un'eccezione per le tabelle o le viste che sono state utilizzate solo da un pacchetto di reporting o esportate in un file CSV.

Molti database hanno limiti rigorosi sul numero di caratteri nel nome di una colonna (ad esempio Oracle).

Se stai lavorando con un database che consente nomi di colonne lunghi, ma in seguito decidi che vuoi migrare quella struttura su un altro sistema di database, i prefissi aumenteranno le possibilità che i nomi delle tue colonne non siano validi.

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

Considera di scrivere un dizionario dei dati (o "registro"). Con ciò intendo un documento contenente tutti gli elementi di dati nel modello: nome, descrizione, ecc. Dovrebbe essere indipendente dall'implementazione del modello, ad es. non dovrebbe menzionare i nomi delle tabelle. Come disambigeresti nomi come "ID", "Tipo" e "Codice"?

Un approccio è seguire le linee guida dello standard internazionale ISO / IEC 11179 - dopo tutto, perché reinventare il 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 carattere di sottolineatura funziona bene visivamente.

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

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

Quindi non penso che la convenzione sui nomi con cui devi lavorare suoni troppo male.

sull'implementazione, ad es. in SQL, ad alcune persone piace omettere gli elementi secondari Oggetto, Qualificatore e Proprietà quando il nome della tabella fornisce il contesto, ad es. person_first_name diventa first_name nella tabella Person ecc. Tuttavia, la regola empirica secondo cui un elemento dati non dovrebbe cambiare il suo nome semplicemente 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 del nome che hanno usato:)

Troverete un bel riassunto di ISO 11179 nel libro Stile di programmazione di Joe Celko , incluse le prove per preferire sottolinea come delimitatori nei nomi di colonne.

Alcuni trovano più facile in 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 abili e mentre scavi più in profondità troverai molte altre convenzioni di codifica sbagliata e se dovessi indovinare l'app ha troppe tabelle, è buggy, ecc.