Convenzioni e best practice per la denominazione dei nomi di colonna

19

Vorrei un parere di esperti sulle migliori pratiche in materia di denominazione delle colonne .

Lo sfondo è che, secondo Wikipedia , la seguente sintassi,

SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);

è più efficiente di

SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);

Tuttavia, la JOIN ... USINGsintassi funziona solo per tutte le colonne chiave primaria hanno nomi univoci a livello globale . Quindi mi chiedo se questo è considerato la cosa giusta da fare.

Personalmente, ho sempre usato per creare tabelle con colonna PK ide colonna chiave esterna othertable_id. Ma in questo modo non è possibile utilizzare USINGo NATURAL JOIN.

Anche i collegamenti a stili di progettazione o guide di buone pratiche per la progettazione di tavoli sarebbero apprezzati!

database-design join naming-convention

— Kerrek SB
fonte

3

Wikipedia è sbagliata. La prima versione non è affatto più efficiente della seconda. Sotto il cofano il database creerà query

— assolutamente

13

Questo è stato chiesto in precedenza su SO.

Dove hai nomi comuni e molto ambigui, quindi prefisso con il nome della tabella. Cioè, qualsiasi cosa tu debba essere alias in quasi ogni query.

Quindi per un tavolo Employee avrei

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

E Wikipedia in realtà dice:

Il costrutto USING è più che semplice zucchero sintattico, tuttavia, poiché il set di risultati differisce dal set di risultati della versione con il predicato esplicito. In particolare, tutte le colonne menzionate nell'elenco USING verranno visualizzate una sola volta, con un nome non qualificato, anziché una volta per ogni tabella nel join.

Questa è una colonna in meno. Non lo useresti mai, SELECT *quindi il punto è discutibile ...

— GBN
fonte

Non avevo pensato di cercare così - sciocco me. Hai collegamenti a domande su SO particolarmente buone? Ad ogni modo, grazie, mi atterrò alla denominazione "ID univoco" d'ora in poi!

— Kerrek SB,

@Kerrk SB: in realtà no. Tendo a ignorarli perché a ciascuno viene data una risposta o chiusa rapidamente :-) Scusa

— gbn

Mi piacerebbe vedere quelle domande simili su SO, se qualcuno può trovare un link. Sono venuto qui perché non riuscivo a trovare una domanda lì, ed ero sicuro che sarebbe già stato posto. Ho trovato immediatamente questa domanda però.

— Nicholas Shanks,

Era su programmers.SE. Una bella battaglia per i grandi panini per te ... programmers.stackexchange.com/questions/114728/…

— gbn

6

Il libro seguente parla dell'utilizzo dell'ID come antipattern SQL e sono d'accordo con l'autore che lo sia. http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1330025134&sr=1-1

Questo è un problema particolare quando si eseguono report complessi e sono necessari più di un ID, poiché è necessario un alias. L'uso dell'ID tablename rende anche più facile l'identificazione dell'FK corretto a cui unirsi (poiché hanno lo stesso nome) e rende meno probabili errori dall'unione alla cosa sbagliata.

Detto questo, molti database non supportano la sintassi USING che rende il problema che hai sollevato non è un problema per questi database. Né molti database supportano l'uso di un join naturale che non consiglierei di utilizzare in nessun modo mentre si uniscono potrebbe cambiare se le strutture della tabella cambiano. Quindi supponiamo di aggiungere un campo chiamato modifieddate ad entrambe le tabelle, non vorresti unirti a questo, ma il join naturale lo farebbe.

— HLGEM
fonte

4

È meglio fornire esplicitamente il nome della tabella e il nome della colonna come Employees.EmployeeID con le espressioni in cui esiste un join

— Eralper
fonte