多くの行を持つ1つのテーブルまたはいくつかの行を持つ多くのテーブル
気になる質問があります。 1つのテーブルを作成してそこに多くの行を格納するか、さまざまなテーブルを作成してそれらにいくつかの行を置く方が良いですか？物理レベルで節約されたパフォーマンスとI/Oはどれくらいですか？ 1つのテーブルではなく、いくつのスペースが多くのテーブルを使用しますか？ Wordpressマルチブログ機能の処理方法を考えています。これは、新しいプロジェクトを開始していて、最善の方法を探しているからです。
同じ種類のエンティティを含むテーブルについて話していると仮定すると、通常は1つのテーブルが必要です。
2つのアプローチの間にパフォーマンスの違いや管理上の大きな違いはなく、単一のテーブルの方が管理が簡単です。通常、大きなテーブルは、適切にインデックスが作成されている場合、同じバージョンの小さなテーブルと比較してパフォーマンスのオーバーヘッドがありません。これは、インデックスのシーク時間が行の成長に比べてゆっくりと増加するためです。
正規化された設計では、エンティティまたはリレーションごとに異なるテーブルがありますが、パーティション化（DBMS機能でサポートされているか、個別のテーブルで手動でサポートされている限り）は、バックアップの粒度や特定の要件がある場合に通常必要です。パーティションごとのデータのロード/アンロード。
これら2つの設定が同等である理由は明らかではありません。通常、1種類のエンティティのすべてのデータを1つのテーブルに格納します。おそらく、「1つのテーブル」にはあるタイプのエンティティが格納されており、そのエンティティの分散の形式を示すフィールドがあります（車両に関する情報を格納するテーブルの「色」など）。 「多くの行を持つ1つのテーブル」に裏打ちされた「いくつかの行を格納する多くのテーブル」のようなビューを作成できます。私はあなたの問題を完全に理解しているとは１００％確信していませんが、理解しているなら、これはそれを解決するための通常のアプローチだと思います。
私はあなたが言及したコンセプトを思います：行が少ない複数のテーブルと複数の行があるいくつかのテーブルは、正規化と非メール化の間のトレードオフにマッピングされています。どちらが良いかという特定のことはありません。それは純粋にアプリケーションのシナリオに依存します。
ワードプレスで言及したようなアプリケーションの場合、データはそれほど多くないので、正規化と非正規化のバランスは私にとってはスキーマ設計を非正規化する傾向があります。
WordPressには、「ユーザー」ごとに数十のテーブルが作成されるという欠点があります。これは、使用する1つのデータベース（ディレクトリ）を膨らませます。 100人のユーザーに問題はありません。ディレクトリ内のファイル数が多いため、1000はOSの速度低下のリスクがあります。