Relationelle databaser er designet til at gemme mange rækker pr. tabel. Der er en hel masse mekanismer til at lette store borde, såsom:
- Indekser på enhver kombination af felter for at fremskynde søgninger
- Sidecaching, så ofte brugte sider forbliver i hukommelsen
- Lodret partitionering (søjledatabaser) til yderligere hastighedsanmodninger
- Avancerede algoritmer såsom hash joins og group bys (i det mindste i andre databaser end MySQL)
- Brug af flere processorer og diske til at behandle forespørgsler
Der er én ting, der er sværere, når man lægger data i en enkelt tabel, og det er sikkerhed. Og faktisk er dette i nogle tilfælde en primær bekymring og kræver grundlæggende, at dataene er i en separat tabel. Disse applikationer er sjældne og langt imellem.
For at give et eksempel på, hvor dårlig lagring af data i flere tabeller kan være, forestil dig, at du i dit system har én post pr. virksomhed, og du gemmer den i en tabel. Denne post gemmer oplysninger om virksomheden - noget som navn, adresse, hvad som helst. Opkald er 100 bytes information.
I dit skema er der en separat tabel for hver "virksomhed", så det er en række pr. tabel. Denne post vil ligge på én dataside. En dataside kunne være på 16 kbyte, så du spilder omkring 15,9 kbyte på at gemme disse data. Lagring af 1000 sådanne poster optager 16 Mbytes i stedet for omkring 7 sider værd (112 Kbytes). Det kan være et betydeligt præstationshit.
Derudover tager du med flere tabeller ikke højde for udfordringerne ved at vedligeholde alle tabellerne og sikre korrektheden af data i de forskellige tabeller. Vedligeholdelsesopdateringer skal anvendes på tusindvis af tabeller i stedet for en håndfuld.