Relationele databases zijn ontworpen om veel rijen per tabel op te slaan. Er zijn een hele reeks mechanismen om grote tafels te vergemakkelijken, zoals:
- Indexen op elke combinatie van velden om zoekopdrachten te versnellen
- Paginacaching zodat veelgebruikte pagina's in het geheugen blijven
- Verticale partitionering (kolomdatabases) om snellere verzoeken te maken
- Geavanceerde algoritmen zoals hash-joins en group-by's (tenminste in andere databases dan MySQL)
- Gebruik van meerdere processors en schijven om query's te verwerken
Er is één ding dat moeilijker is bij het plaatsen van gegevens in een enkele tabel, en dat is beveiliging. En in feite is dit in sommige omstandigheden een primaire zorg en vereist het in feite dat de gegevens in een aparte tabel worden geplaatst. Die toepassingen zijn zeldzaam en ver tussen.
Om een voorbeeld te geven van hoe slecht het opslaan van gegevens in meerdere tabellen kan zijn:stel je voor dat je in je systeem één record per bedrijf hebt en dat in een tabel opslaat. Dit record bevat informatie over het bedrijf -- zoiets als naam, adres, wat dan ook. Oproep is 100 bytes aan informatie.
In je schema staat voor elk "bedrijf" een aparte tabel, dat is dus één rij per tabel. Dat record bevindt zich op één gegevenspagina. Een gegevenspagina kan 16 kbytes zijn, dus u verspilt ongeveer 15,9 kbytes om deze gegevens op te slaan. Het opslaan van 1000 van dergelijke records neemt 16 Mbytes in beslag in plaats van ongeveer 7 pagina's (112 Kbytes). Dat kan een aanzienlijke prestatiehit zijn.
Bovendien houdt u met meerdere tabellen geen rekening met de uitdagingen van het onderhouden van alle tabellen en het waarborgen van de juistheid van gegevens in de verschillende tabellen. Onderhoudsupdates moeten worden toegepast op duizenden tafels, in plaats van op een handvol.