2

すべてのレストラン データを同じテーブルに格納するためのテーブルを使用するプロジェクトに取り組んでいます。area_idとを含むエリアについては、別の表があります。area_name

私にとって問題の原因となっているフィールドは 6 つあります。彼らです:

delivery_area_1 , delivery_area_2, delivery_area_3
minimum_order_1, minimum_order_2 and minimum_order_3

delivery_area_1フィールドには、レストランが最小注文 1 で配達するすべての のコンマ (',') で区切られたリストがarea_id含まれ、配達エリア 2 および 3 についても同様です。

ユーザーが で検索しarea_id、結果にその area_id で配達するすべてのレストランが含まれている場合、対応する最小注文が他の詳細とともに結果に表示されます。

この配達地域のデータを別のマッピング テーブルに移動することを提案します。

restaurant_id, area_id and the minimum order.

ただし、これを行うと、マッピング テーブルのエントリ数が 20,000 のレストランに対して 1000,000 を超えることになります。現在1000店舗ありますが、これからどんどん増えていきます。各レストランは、約 30 ~ 80 の地域で配達します。

これは良い動きですか?それは大きな決断でしょう。ですから、アプローチを手伝ってください。

検索を簡素化して最適化するより良い方法はありますか?

そのPHPウェブサイト。

4

2 に答える 2

2

短くて簡単:はい、それを変更します (これはデータベースの正規化と呼ばれます)。

3 つの列だけを含むテーブルに 100 万行あることは大したことではありません。1 つだけではなく 2 つのテーブルを追加することもできます。

minimum_order (restaurant_id, minimum_order_id, amount)

delivery_area (restaurant_id, area_id, minimum_order_id)

これにより、エリアのグループの量が変更されるという利点が得られます。minimum_order複数の行 (エリアごとに 1 つ) ではなく、 の量だけを更新する必要がありますminimum_order

于 2012-05-09T09:00:57.560 に答える
0

これは間違いなく良い動きです。行数を減らすためにデータベースを非正規化することはお勧めできません。それを行うことにはいくつかの欠点があります。現在、エリア ID をカンマ区切りで保存しているようです。その場合、エリア ID による検索ではインデックスを使用できません。または、delivery_area_1、delivery_area_2、delivery_area_3 フィールドに「全文索引」を使用した可能性があります。

行数が増えている場合は、パーティショニング手法を試すことができます。

http://dev.mysql.com/tech-resources/articles/partitioning.htmlを参照してください。

于 2012-05-09T09:15:41.343 に答える