Il mio consiglio sulla modellazione dei dati è:
- Dovresti privilegiare le colonne facoltative (annullabili) rispetto ai join 1:1 in generale . Ci sono ancora casi in cui 1:1 ha senso, di solito ruota attorno alla sottotipizzazione. Le persone tendono ad essere più schizzinose quando si tratta di colonne annullabili rispetto a quanto non facciano stranamente sui join;
- Non fare un modello anche tu indiretto a meno che davvero giustificato (più su questo sotto);
- Il favore si unisce all'aggregazione. Questo può variare, quindi deve essere testato. Vedere Oracle vs MySQL vs SQL Server:aggregazione vs Join per un esempio di questo;
- I join sono migliori di N+1 selezioni. Una selezione N+1 consiste, ad esempio, nella selezione di un ordine da una tabella del database e quindi nell'emissione di una query separata per ottenere tutti gli elementi pubblicitari per quell'ordine;
- La scalabilità dei join è solitamente solo un problema quando si effettuano selezioni di massa. Se selezioni una singola riga e poi la unisci ad alcune cose, raramente questo è un problema (ma a volte lo è);
- Le chiavi straniere dovrebbero sempre essere indicizzato a meno che tu non abbia a che fare con una tabella banalmente piccola;
Altro in Errori di sviluppo del database commessi dagli sviluppatori di app .
Ora per quanto riguarda l'immediatezza di un modello, lasciate che vi faccia un esempio. Diciamo che stai progettando un sistema per l'autenticazione e l'autorizzazione degli utenti. Una soluzione sovradimensionata potrebbe assomigliare a questa:
- Alias (id, nome utente, user_id);
- Utente (id, ...);
- E-mail (id, user_id, indirizzo e-mail);
- Accesso (id, user_id, ...)
- Ruoli di accesso (id, login_id, role_id);
- Ruolo (id, nome);
- Privilegio ruolo (id, role_id, privilegio_id);
- Privilegio (id, nome).
Quindi hai bisogno di 6 join per ottenere dal nome utente inserito i privilegi effettivi. Certo potrebbe esserci un reale requisito per questo, ma il più delle volte questo tipo di sistema viene inserito a causa della stretta di mano da parte di alcuni sviluppatori che pensano che un giorno potrebbero averne bisogno anche se ogni utente ha un solo alias, l'utente per accedere è 1 :1 e così via. Una soluzione più semplice è:
- Utente (id, nome utente, indirizzo email, tipo utente)
e, beh, questo è tutto. Forse se hai bisogno di un sistema di ruoli complesso, ma è anche del tutto possibile che non lo sia e se lo fai è ragionevolmente facile da inserire (il tipo di utente diventa una chiave esterna in una tabella dei tipi di utente o dei ruoli) oppure è generalmente semplice mappare il vecchio al nuovo.
Questa è una questione di complessità:è facile da aggiungere e difficile da rimuovere. Di solito è una veglia costante contro la complessità non intenzionale, che è già abbastanza grave senza peggiorare la situazione aggiungendo complessità non necessaria.
