Quando suddividere i modelli in più tabelle di database?

Question

Sto lavorando con Ruby on Rails, ma questa domanda penso sia più ampia di quella e si applica generalmente al design del database.

Quando è una buona idea dividere un singolo modello in più tabelle? Ad esempio, supponiamo di avere un modello Utente e il numero di campi nel modello sta davvero iniziando a sommarsi. Ad esempio, l'Utente può inserire il suo sito web, il suo compleanno, il suo fuso orario, il suo ecc.

C'è qualche vantaggio o svantaggio nel suddividere il modello, in modo tale che forse la tabella Utente abbia solo informazioni di base come login e e-mail, e poi c'è un'altra tabella che ogni utente ha che è qualcosa come UserInfo, e un'altra che è UserPermissions, e un'altra che è UserPrivacySettings o qualcosa del genere?

Modifica: per aggiungere ulteriore lucentezza su questo, la maggior parte dei campi è raramente accessibile, tranne che per le pagine ad essi specifiche. Ad esempio, le cose come il compleanno sono accessibili solo se qualcuno fa clic sul profilo di un utente. Inoltre, alcuni dei campi (che sono raramente accessibili) hanno il potenziale per essere estremamente grandi. La maggior parte dei campi ha il potenziale per essere impostata o vuota o nulla.

Answer 1

Questa sarebbe una situazione per l'analisi.

Quando si scopre che molti dei campi in tale tabella sono NULL, e possono essere raggruppati (ad es. UserContactInfo), è tempo di guardare estrarre le informazioni al proprio tavolo.

Si vuole evitare di avere una tabella con decine/centinaia di campi con solo dati scarsamente inseriti.

Piuttosto, provare a raggruppare i dati in modo logico e crare la tabella principale che contiene i campi che sono per lo più tutti popolati. Quindi puoi creare sottoinsiemi di dati, quasi come li rappresenterai nell'interfaccia utente (informazioni di contatto, interesse personale, informazioni relative al lavoro, ecc.) In tabelle separate.

Answer 2

Il recupero di una riga è più costoso se ha molte colonne, soprattutto se di solito sono necessari solo alcuni campi. Inoltre, l'hosting di elementi come i componenti di un indirizzo in una classe separata è un caso di DRY. D'altra parte, se hai bisogno di tutti i campi di un oggetto, ci vuole più tempo per eseguire una query composta.

Normalmente non mi occupo di distribuire le classi su più tabelle solo per rendere il codice più leggibile (cioè senza parti effettivamente riusabili come indirizzi).

Answer 3

Generalmente è una buona idea mettere le cose che hanno una relazione uno a uno nella stessa tabella. A meno che la tua base utente includa il Queen o Paddington Bear, un utente ha solo un compleanno, quindi dovrebbe essere un attributo della tabella USERS. Le cose che hanno una relazione uno-a-molti dovrebbero essere in tabelle separate. Quindi, se un utente può avere più impostazioni di privacy, separarle in ogni caso.

La suddivisione di una tabella in più tabelle può rendere le query più complicate o più lente, se vogliamo recuperare tutte le informazioni dell'utente in una volta. D'altra parte, se disponiamo di un insieme di attributi che vengono sempre interrogati o aggiornati in modo discreto, disporre di una tabella separata per contenere tali dati è un'idea valida.