多くの列といくつかのテーブル-パフォーマンスの面で

はい、私はデータの正規化が（現状のまま）私の優先事項であることを認識しています。

1. 私は列の車両データを格納する65個の列を持つテーブルを持っている：used_vehicle、color、doors、mileage、priceなど、合計65インチ
2. 今、私はそれを分割して持つことができるVehicleテーブル、VehicleInterior、VehicleExterior、VehicleTechnical、VehicleExtra（すべての一対一のメインとVehicleテーブル）。

約500万行（車両）があるとします。

上SELECTでのWHERE句：パフォーマンスが（どちらの場合は、上の少なくともインデックスを付けて検索するほうが良いでしょうIDs）：

1. Vehicle 65列のテーブルまたは
2. VehicleテーブルJOINSに関連するすべてのデータを返すために、他の4つのテーブル（すべてで5万行）にVehicle？

（データベースエンジンごとに、PostgreSQLやMySQLを検討してください）。

以前の経験から得られた詳細な洞察を本当に感謝しますか？

すべてのテーブル間の1対1の関係について話していると仮定します。

全体的なストレージは、実質的に常に（実質的に）安価であり、1：1の関係にある複数のテーブルではなく、単一のテーブルを使用します。各行には28バイトのオーバーヘッドがあり、通常は追加の埋め込み用にさらに数バイト追加されます。そして、すべてのテーブルにPK列を格納する必要があります。そして、これらの各列に個別の（冗長な）インデックスを付けます...サイズはパフォーマンスにとって重要です。

NULLストレージは非常に安価であるため、ほとんどの行で多くの列がNULLである場合も同様です。

• 読み取りパフォーマンスのためのPostgreSQLの構成

すべての列を取得する一方で、単一のテーブルは、5つのテーブルを結合するよりも大幅に高速です。また、はるかに簡単です。すべてのテーブルにすべての行が存在するわけではない場合、5つのテーブルを結合するのは難しいかもしれません。WHERE条件は、単一のテーブルを対象に、それはで他のテーブルを追加するための簡単な十分ですLEFT JOIN。複数のテーブルに述語がある場合、それほど簡単ではありません...

垂直分割 により、特定のクエリのパフォーマンスが向上する場合があります。たとえば、クエリの90％が65の利用可能な列から同じ5つの列を取得する場合、これらの5つの列を保持しているテーブルの方が高速です。

• クエリ中にディスクから何が取得されますか？（私の答え）

OTOH、インデックスのみのスキャンを可能にする「カバーリング」インデックスを使用して、選択したいくつかの列でこのようなクエリに対応できる場合があります。

垂直分割の別の候補：ほんの数列で多くの更新があり、残りはほとんど変更されない場合。Postgresは更新ごとに新しい行バージョンを書き込むため、このような場合に行を分割する方がはるかに安価になる場合があります。行外に格納された（ "TOASTed"）大きな値には例外があります。詳細：

• クエリ中にディスクから何が取得されますか？（ダニエルの答え）
• 別のテーブルのすべての列を更新する

それは本当に完全な状況に依存します。疑わしい場合は、単一のテーブルを使用するという単純な解決策を使用してください。特に、それが現実をよく表している場合はそうです。例では、これらはすべて車の属性であり、一緒に意味をなしています。

単一のテーブルでの選択は常に高速である必要があります。あなたがあなたの車を見つけたらすぐにあなたはすでにすべての詳細を持っています。

ただし、正規化の効率は失われます。たとえば、1台の車にさまざまなオプションを持つ多くのモデルがあったとします。

これはすべての車の参照データベースですか？または中古車のリスト？同じオプションで同じメーカー/モデルの多くの例がありますか？

編集：私の回答は、postgres固有ではなく、一般的なrdbmsであると見なす必要があります。@Erwinのpostgres固有の詳細な回答に従います