I database relazionali sono progettati per memorizzare molte righe per tabella. Ci sono un sacco di meccanismi per facilitare tavoli di grandi dimensioni, come:
- Indici su qualsiasi combinazione di campi per velocizzare le ricerche
- La memorizzazione nella cache delle pagine in modo che le pagine di uso comune rimangano in memoria
- Partizionamento verticale (database colonna) per velocizzare ulteriormente le richieste
- Algoritmi avanzati come hash join e group by (almeno in database diversi da MySQL)
- Utilizzo di più processori e dischi per elaborare le query
C'è una cosa che è più difficile quando si mettono i dati in una singola tabella ed è la sicurezza. E, in effetti, in alcune circostanze questa è una preoccupazione primaria e richiede sostanzialmente che i dati vadano in una tabella separata. Queste applicazioni sono rare e lontane tra loro.
Per fornire un esempio di quanto potrebbe essere pessima la memorizzazione dei dati in più tabelle, immagina di avere un record per azienda nel tuo sistema e di archiviarlo in una tabella. Questo record memorizza le informazioni sull'azienda, qualcosa come nome, indirizzo, qualunque cosa. La chiamata è di 100 byte di informazioni.
Nel tuo schema c'è una tabella separata per ogni "azienda", quindi è una riga per tabella. Quel record risiederà su una pagina di dati. Una pagina di dati potrebbe essere di 16 kbyte, quindi stai sprecando circa 15,9 kbyte per archiviare questi dati. La memorizzazione di 1000 di questi record occupa 16 Mbyte invece di circa 7 pagine (112 Kbyte). Questo può essere un notevole successo in termini di prestazioni.
Inoltre, con più tabelle non si tiene conto delle sfide legate alla conservazione di tutte le tabelle e alla garanzia della correttezza dei dati nelle diverse tabelle. Gli aggiornamenti di manutenzione devono essere applicati a migliaia di tabelle, anziché a una manciata.
