Esiste una convenzione di denominazione per MySQL?


163

Ecco come lo faccio:

  1. I nomi delle tabelle sono minuscole, usi sottolineatura per separare le parole, e sono singolari (ad esempio foo, foo_bare così via
  2. In genere (non sempre) ho un PK di incremento automatico. Uso la seguente convenzione: tablename_id(ad es foo_id. foo_bar_id, Ecc.).
  3. Quando una tabella contiene una colonna che è una chiave esterna, copio semplicemente il nome della colonna di quella chiave da qualunque tabella provenga. Ad esempio, supponiamo che la tabella foo_barabbia l'FK foo_id(dov'è foo_idil PK di foo).
  4. Quando definisco gli FK per applicare l'integrità referenziale, utilizzo quanto segue: tablename_fk_columnname(ad esempio, per promuovere l'esempio 3, sarebbe foo_bar_foo_id). Poiché si tratta di una combinazione di nome tabella / nome colonna, è garantito che sia univoco all'interno del database.
  5. Ordino le colonne in questo modo: PK, FK, quindi il resto delle colonne in ordine alfabetico

Esiste un modo migliore e più standard per farlo?


6
È sbagliato usare per PK l'incremento automatico solo "id"? Perché? Il nome della colonna ha significato solo nel contesto della tabella. Quindi ho un "id" in ogni tabella e potrei avere molti id_ <table_name> per FK.
Zbyszek,

3
@Zbyszek Penso che la ragione più semplice per farlo sia semplicemente per coerenza / semplicità. Invece di avere id_tableB=> oh nessuna colonna con un nome diverso id , la consistenza di id_tableB=> id_tableBsembra solo più ordinata ... o come OP fa: foo_id=> foo_idpiuttosto che foo_id=>id
Don Cheadle,

Risposte:


106

Direi che prima di tutto: essere coerenti.

Suppongo che tu ci sia quasi con le convenzioni che hai delineato nella tua domanda. Un paio di commenti però:

I punti 1 e 2 sono buoni, credo.

Punto 3 - purtroppo questo non è sempre possibile. Pensa a come faresti con una singola tabella foo_barcon colonne foo_ided another_foo_identrambe le quali fanno riferimento alla colonna della footabella foo_id. Potresti voler considerare come affrontarlo. Questo è un po 'un caso angolare però!

Punto 4 - Simile al punto 3. È possibile che si desideri introdurre un numero alla fine del nome della chiave esterna per soddisfare più di una colonna di riferimento.

Punto 5 - Eviterei questo. Ti fornisce poco e diventerà un mal di testa quando vuoi aggiungere o rimuovere colonne da una tabella in un secondo momento.

Alcuni altri punti sono:

Convenzioni di denominazione dell'indice

Potresti voler introdurre una convenzione di denominazione per gli indici: questo sarà di grande aiuto per qualsiasi lavoro sui metadati del database che potresti voler eseguire. Ad esempio, potresti semplicemente voler chiamare un indice foo_bar_idx1o foo_idx1, totalmente da te, ma vale la pena considerare.

Nomi delle colonne singolari e plurali

Potrebbe essere una buona idea affrontare il problema spinoso del plurale contro singolo nei nomi delle colonne e dei nomi delle tabelle. Questo argomento provoca spesso grandi dibattiti nella comunità DB. Attaccherei con forme singolari sia per i nomi delle tabelle che per le colonne. Là. L'ho detto.

La cosa principale qui è ovviamente la coerenza!


Cosa sarebbe meglio del punto 5? Perché potrebbe diventare un mal di testa?
Rasshu,

8
A seguire, ho trovato questo molto utile per coloro che verranno qui più tardi: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/…
Enissay

1
Ho difficoltà a trovare un buon "schema" per nominare le mie tabelle che contengono oggetti di modelli costituiti da due nomi (DocumentChapter, DocumentVersion, DocumentType ecc.). Ad esempio per DocumentType potrei nominarlo documenttypeo document_type. Preferirei quest'ultima, ma la maggior parte delle volte ho molte o molte relazioni e ho bisogno di un tavolo che assomigli document_document_type. Qualche suggerimento su come gestirlo?
Lexith

@ rsb2097 Ri: punto 5 - Dopo aver aggiunto una colonna (alla fine) l'ordine potrebbe non essere valido. Non è necessario aggiungere alcun vincolo che richiede il riordino delle colonne in quanto si tratta di un sovraccarico non necessario.
Will Sheppard,

21

La coerenza è la chiave per qualsiasi standard di denominazione. Finché è logico e coerente, sei lì al 99%.

Lo standard in sé è una preferenza molto personale, quindi se ti piace il tuo standard, corri con esso.

Per rispondere apertamente alla tua domanda - no, MySQL non ha una convenzione / standard di denominazione preferito, quindi il roll-up della tua va bene (e la tua sembra logica).



4

Per fortuna, gli sviluppatori PHP non sono "fanatici dei cammelli" come alcune comunità di sviluppo che conosco.

Le tue convention suonano bene.

Solo finché sono a) semplici eb) coerenti - non vedo alcun problema :)

PS: Personalmente, penso che 5) sia eccessivo ...


2
Lungi dall'essere bigotti, il caso del cammello è in realtà disapprovato da molti della comunità DB perché alcuni dei RDBMS non fanno distinzione tra maiuscole e minuscole al punto in cui spogliano i casi (o cambiano tutto in maiuscolo), quindi le cose diventano davvero brutte molto rapidamente.
mal-wan,

@mwan: puoi specificare quale RDBMS '? E io stesso sono un fantino da caso di cammelli. Le maiuscole servono solo uno scopo nel mio schema, per indicare le tabelle di join e (nel caso dei campi) per indicare i confini delle parole, in modo che _ possa essere esclusivamente per indicare un altrotable_id (cioè nome tabella = othertable e campo in quella tabella = id ). Inoltre, se l'altro RDBMS non fa distinzione tra maiuscole e minuscole, che importanza ha davvero? Non avrò mai una versione maiuscola e minuscola della stessa tabella! Oh, e non preferirei un RDBMS senza distinzione tra maiuscole e minuscole - Preferirei scrivere un codice coerente
Samuel Fullman

7
Mi piace l'ironia degli utenti di MySQL che non amano CamelCase e il nome del prodotto che utilizziamo: MySQL, scritto in CamelCase
DBX12,

1
@ DBX12 Per essere pedanti, questo è PascalCase, non camelCase, ma il tuo punto è ancora valido.
MarredCheese,

@MarredCheese Non ci ho mai pensato, ma hai ragione. camelCase non dovrebbe avere gobba all'inizio.
DBX12,

1

Risposta semplice: NO

Bene, almeno una convenzione di denominazione come tale incoraggiata da Oracle o dalla comunità, no, tuttavia, in sostanza devi essere consapevole di seguire le regole e i limiti per gli identificatori, come indicato nella documentazione di MySQL: https://dev.mysql.com /doc/refman/8.0/en/identifiers.html

A proposito della convenzione di denominazione che segui, penso che sia ok, solo il numero 5 è un po 'inutile, penso che la maggior parte degli strumenti visivi per la gestione dei database offrono un'opzione per ordinare i nomi delle colonne (io uso DBeaver e ce l'ho), quindi se il purpouse ha una bella presentazione visiva del tuo tavolo, puoi usare questa opzione che menziono.

Per esperienza personale, consiglierei questo:

  • Usa lettere minuscole . Ciò garantisce quasi l'interoperabilità durante la migrazione dei database da un server a un altro. A volte lower_case_table_namesnon è configurato correttamente e il tuo server inizia a lanciare errori semplicemente non riconoscendo lo standard camelCase o PascalCase (problema di distinzione tra maiuscole e minuscole).
  • Nomi brevi . Semplice e chiaro Il più semplice e veloce è identificare la tua tabella o colonne, meglio è. Fidati di me, quando fai molte domande diverse in un breve lasso di tempo è meglio avere tutto semplice da scrivere (e leggere).
  • Evita i prefissi . A meno che non si stia utilizzando lo stesso database per tabelle di applicazioni diverse, non utilizzare i prefissi. Questo aggiunge solo più verbosità alle tue domande. Esistono situazioni in cui ciò può essere utile, ad esempio, quando si desidera identificare chiavi primarie e chiavi esterne, che di solito i nomi delle tabelle vengono utilizzati come prefisso per le colonne ID.
  • Usa i trattini bassi per separare le parole . Se vuoi ancora usare più di una parola per nominare una tabella, una colonna, ecc., Quindi usa i trattini bassi per separare le parole , questo aiuta per la leggibilità (i tuoi occhi e il tuo cervello stressato ti ringrazieranno).
  • Sii coerente . Una volta che hai il tuo standard, seguilo. Non essere la persona che crea le regole ed è il primo che le infrange, è vergognoso.

E che dire della denominazione "Plural vs Singular"? Bene, questa è soprattutto una situazione di preferenze personali. Nel mio caso cerco di usare nomi plurali per le tabelle perché penso che una tabella sia una raccolta di elementi o un pacchetto contenente elementi, quindi un nome plurale ha senso per me; e nomi singolari per le colonne perché vedo le colonne come attributi che descrivono singolarmente a quegli elementi della tabella.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.