Denominazione tabella: trattino basso vs Camelcase? spazi dei nomi? Singolare vs Plurale?

Ho letto un paio di domande / risposte su StackOverflow cercando di trovare il "migliore", o forse dovrei dire il modo accettato, per nominare le tabelle su un database.

La maggior parte degli sviluppatori tende a denominare le tabelle in base alla lingua che richiede il database (JAVA, .NET, PHP, ecc.). Tuttavia sento che non è giusto.

Il modo in cui ho nominato le tabelle fino ad ora sta facendo qualcosa del tipo:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents 

Le cose che mi interessano sono:

• Leggibilità
• Identificazione rapida del modulo da cui proviene il tavolo (medici || pazienti)
• Facile da capire, per evitare confusioni.

Vorrei leggere tutte le opinioni sulle convenzioni di denominazione. Grazie.

Essere coerenti è molto più importante di quale particolare schema usi.

Di solito uso PascalCase e le entità sono singolari:

DoctorMain
DoctorProfile
DoctorPatient

Imita le convenzioni di denominazione per le classi nella mia applicazione mantenendo tutto abbastanza ordinato, pulito, coerente e facile da capire per tutti.

Natura senza distinzione tra maiuscole e minuscole dei supporti SQL Underscores_Scheme. Il software moderno tuttavia supporta qualsiasi tipo di schema di denominazione. Tuttavia a volte possono portare a bug, errori o fattori umani fastidiosi in UPPERCASINGEVERYTHINGmodo che coloro che hanno selezionato entrambi Pascal_Casee lo Underscore_Caseschema vivano con tutti i nervi al posto giusto.

Un'aggregazione della maggior parte di quanto sopra:

• non fare affidamento sul caso nel database
• non considerare il caso o il separatore come parte del nome, solo le parole
• usa qualunque separatore o caso sia lo standard per la tua lingua

Quindi puoi tradurre facilmente (anche automaticamente) i nomi tra gli ambienti.

Ma aggiungerei un'altra considerazione: potresti scoprire che ci sono altri fattori quando passi da una classe nella tua app a una tabella nel tuo database: l'oggetto database ha viste, trigger, processi archiviati, indici, vincoli, ecc. servono anche nomi. Così, ad esempio, potresti trovarti ad accedere solo alle tabelle tramite le viste che in genere sono solo un semplice "seleziona * da foo". Questi possono essere identificati come il nome della tabella con solo un suffisso di "_v" oppure è possibile inserirli in uno schema diverso. Lo scopo di un livello di astrazione così semplice è che può essere espanso quando necessario per consentire modifiche in un ambiente per evitare di influire sull'altro. Ciò non interromperà i suggerimenti di denominazione di cui sopra, solo alcune altre cose di cui tenere conto.

Uso i trattini bassi. Ho fatto un progetto Oracle alcuni anni fa, e sembrava che Oracle avesse forzato tutti i nomi dei miei oggetti in lettere maiuscole, il che fa saltare qualsiasi schema di case. Non sono davvero un ragazzo Oracle, quindi forse c'era un modo per aggirare questo di cui non ero a conoscenza, ma mi ha fatto usare i trattini bassi e non sono mai tornato indietro.

Poiché la domanda non è specifica per una particolare piattaforma o motore DB, devo dire per la massima portabilità, dovresti sempre usare nomi di tabella in minuscolo.

/ [a-z _] [a-z0-9 _] * / è in realtà l'unico modello di nomi che si traduce perfettamente tra piattaforme diverse. Alfanumerico minuscolo + trattino basso funzioneranno sempre in modo coerente.

Come accennato altrove, i nomi delle relazioni (tabelle) dovrebbero essere singolari: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

Tendo ad essere d'accordo con le persone che dicono che dipende dalle convenzioni del linguaggio che stai usando (ad esempio PascalCase per C # e snake_case per Ruby).

Mai camelCase, però.

Dopo aver letto molte altre opinioni, penso che sia molto importante usare le convenzioni di denominazione del linguaggio, la coerenza è più importante delle convenzioni di denominazione solo se sei (e sarai) l'unico sviluppatore dell'applicazione. Se vuoi la leggibilità (che è di enorme importanza) è meglio usare le convenzioni di denominazione per ogni lingua. In MySQL, ad esempio, non suggerisco di utilizzare CamelCase poiché non tutte le piattaforme fanno distinzione tra maiuscole e minuscole. Quindi qui la sottolineatura va meglio.

Questi sono i miei cinque centesimi. Sono giunto alla conclusione che se per un progetto vengono utilizzati DB di diversi fornitori, ci sono due modi migliori:

1. Usa trattini bassi.
2. Usa la custodia del cammello con le virgolette.

Il motivo è che alcuni database convertiranno tutti i caratteri in maiuscolo e alcuni in minuscolo. Quindi, se ce myTablel' hai lo diventerai MYTABLEo mytablequando lavorerai con DB.

Purtroppo non esiste una risposta "migliore" a questa domanda. Come ha affermato @David, la coerenza è molto più importante della convenzione di denominazione.

c'è un'ampia variabilità su come separare le parole, quindi dovrai scegliere quello che preferisci; ma allo stesso tempo, sembra che ci sia quasi consenso sul fatto che il nome della tabella debba essere singolare.

Le convenzioni di denominazione esistono nell'ambito di una lingua e lingue diverse hanno convenzioni di denominazione diverse.

SQL non fa distinzione tra maiuscole e minuscole per impostazione predefinita; quindi, snake_case è una convenzione ampiamente utilizzata. SQL supporta anche identificatori delimitati; quindi, maiuscole e minuscole in un'opzione, come camelCase (Java, dove campi == colonne) o PascalCase (C #, dove tabelle == classi e colonne == campi). Se il tuo motore DB non può supportare lo standard SQL, questo è il suo problema. Puoi decidere di conviverci o scegliere un altro motore. (E perché C # doveva essere diverso è un punto di aggravamento per quelli di noi che codificano in entrambi.)

Se intendi utilizzare una sola lingua nei tuoi servizi e applicazioni, utilizza le convenzioni di quella lingua a tutti i livelli. Altrimenti, utilizza le convenzioni della lingua più utilizzate nel dominio in cui viene utilizzata quella lingua.