リレーショナルデータベースは、テーブルごとに多くの行を格納するように設計されています。次のような大きなテーブルを容易にするメカニズムはたくさんあります。
- 検索を高速化するためのフィールドの任意の組み合わせのインデックス
- ページのキャッシュにより、一般的に使用されるページはメモリに残ります
- リクエストをさらに高速化するための垂直分割（列型データベース）
- ハッシュ結合やグループ化などの高度なアルゴリズム（少なくともMySQL以外のデータベースでは）
- クエリを処理するための複数のプロセッサとディスクの使用
データを1つのテーブルに配置する場合、さらに難しいことが1つあります。それは、セキュリティです。実際、状況によってはこれが主な懸念事項であり、基本的にデータを別のテーブルに配置する必要があります。これらのアプリケーションはまれであり、その間にあります。
複数のテーブルにデータを保存するのがいかに悪いかを示す例として、システムに会社ごとに1つのレコードがあり、それをテーブルに保存するとします。このレコードには、会社に関する情報（名前、住所など）が格納されます。呼び出しは100バイトの情報です。
スキーマには、「会社」ごとに個別のテーブルがあるため、テーブルごとに1行になります。そのレコードは1つのデータページに存在します。データページは16キロバイトになる可能性があるため、このデータを保存するために約15.9キロバイトを浪費しています。このようなレコードを1000個保存すると、約7ページ（112 Kバイト）ではなく16Mバイトになります。これは、パフォーマンスに大きな打撃を与える可能性があります。
さらに、複数のテーブルを使用する場合、すべてのテーブルを維持し、異なるテーブルのデータの正確性を確保するという課題を考慮していません。メンテナンスの更新は、少数ではなく、数千のテーブルに適用する必要があります。