私は何が最善の解決策になるのだろうかと思っています（パフォーマンスの観点から）。特定のOrderShipmentリレーションを持つことができるOrdersテーブルがあります。 OrderShipmentは、通常の配送またはサービスポイントでの配達（オランダでは、スーパーマーケットやビデオストアなどの自宅でも自宅でもない場合のドロップオフポイント）の場合があります。
現在、Order-tableのHasOrderShipmentフィールドを使用して、Shipmentを取得するために2番目のクエリを実行する必要があるかどうかを判断しています。
顧客がで配達を選択したときサービスポイントこのサービスポイントのアドレスの詳細を保存する必要があります。ここで、パフォーマンスの観点から、OrderShipmentテーブルをアドレスフィールドで拡張するか（サービスポイントの配信を除く他のすべての場合はこれらのフィールドをNULLのままにする）、またはアドレスの詳細が格納されるHasOrderShipmentServicePointAddressテーブルを作成する必要があります。
注文テーブルは約520万行で、1日あたり約21.500件の注文で増加します（2011年1月1日から2011年1月23日までの平均）。
回答：
回答№1は0ええと、テーブルがこんなに小さいので、私はしません個人的にはそれについてあまり心配しすぎています（そして、はい、500万行はデータベースの観点からはかなり小さいです）。クエリが遅すぎませんか？もしそうなら、それを最適化します。そうでない場合は、心配しないでください。
さて、あなたの特定の質問に関しては、十分なデータがある場合は、要約テーブルの作成を回避できる可能性があります。 MySQLはマテリアライズドビュー（インデックスが作成されてディスクに保存されるビュー）をサポートしていないため、ビューを追加してもパフォーマンスの観点からはあまり役に立ちません（ただし、読みやすさには役立ちます）。代わりに、サマリーテーブルを追加できます。要約テーブルは、特定のクエリの結果になります。したがって、正規化されたテーブルに余分な列を追加する代わりに、テーブルをコピーして新しい列に列を追加し、トリガーを使用して更新を維持します。別のテーブルでこれを行う理由は、まだ正規化されたテーブルは、参照整合性を適用し、正規化されたデータでより効率的なクエリを実行します。ただし、複雑な結合を行う必要があるクエリ（基本的には結合を事前に計算している）には、サマリーテーブルを使用できます。
しかし、繰り返しになりますが、必要がない限り、このようなことを考えないでください。最適化のために通常のルートを試してください（インデックス、 EXPLAIN、クエリの書き換え、RAMの追加など）を最初に行います。最後の手段として要約表を使用してください...