Relacyjne bazy danych są przeznaczone do przechowywania wielu wierszy na tabelę. Istnieje cała masa mechanizmów ułatwiających obsługę dużych stołów, takich jak:
- Indeksy dowolnej kombinacji pól w celu przyspieszenia wyszukiwania
- Buforowanie stron, więc często używane strony pozostają w pamięci
- Pionowe partycjonowanie (kolumnowe bazy danych) w celu dalszego przyspieszenia żądań
- Zaawansowane algorytmy, takie jak łączenia haszujące i bys grupowych (przynajmniej w bazach danych innych niż MySQL)
- Korzystanie z wielu procesorów i dysków do przetwarzania zapytań
Jest jedna rzecz, która jest trudniejsza podczas umieszczania danych w jednej tabeli, a jest to bezpieczeństwo. W rzeczywistości w niektórych okolicznościach jest to główny problem i zasadniczo wymaga, aby dane były umieszczone w osobnej tabeli. Te aplikacje są rzadkie i rzadko spotykane.
Aby dać przykład, jak złe może być przechowywanie danych w wielu tabelach, wyobraź sobie, że w swoim systemie masz jeden rekord na firmę i przechowujesz go w tabeli. W tym rekordzie przechowywane są informacje o firmie -- coś jak nazwa, adres, cokolwiek. Wywołanie to 100 bajtów informacji.
W twoim schemacie jest osobna tabela dla każdej „firmy”, więc jest to jeden wiersz na tabelę. Ten rekord będzie się znajdował na jednej stronie danych. Strona danych może mieć 16 kB, więc marnujesz około 15,9 kB na przechowywanie tych danych. Przechowywanie 1000 takich rekordów zajmuje 16 MB zamiast około 7 stron (112 KB). To może być znaczącym spadkiem wydajności.
Ponadto przy wielu tabelach nie bierzesz pod uwagę wyzwań związanych z utrzymaniem wszystkich tabel i zapewnieniem poprawności danych w różnych tabelach. Aktualizacje konserwacyjne muszą być stosowane do tysięcy tabel, zamiast kilku.
