0

私はいくつかの広告ウェブサイトを作ろうとしています。いくつかのオープン ソースの広告プロジェクトを見つけました: osclass

ということで、osclassを参考にデータベース構造を設計しようと思います。osclass のデータベース構造は次のように設計されています。

カテゴリ項目データ テーブルは、次のような 7 つの小さなデータ テーブルに分割されています。

oc_t_item: Stores some base item information.
oc_t_item_comment: Stores the comment for item.
oc_t_item_description: Stores title, content for the item.
oc_t_item_location: Store the location information for the item.
oc_t_item_meta: Store some extra meta information for the item.
oc_t_item_resource: Store the image resources information for the item.

しかし、論理と構造を明確にすることはできますが、これは賢明な動きではないと思います。あるカテゴリ アイテムに関する情報を取得したい場合、これらのデータ テーブル間で非常に多くの結合操作を行う必要があり、パフォーマンスが大幅に低下します。では、大きなデータ テーブルをいくつかの小さなデータ テーブルに分割するための基本原則とベスト プラクティスは何でしょうか?

4

1 に答える 1

1

sを懸念して、そのようにテーブルを分割する必要はありませんjoin。関連するテーブルが正しい列を持つ FK またはインデックスの主キーを使用する場合、データの取得は非常に効率的です。クエリが正しいインデックス、参照などを使用していることを確認するためにクエリ分析を使用する方法の例については、この投稿とコメント+回答を参照してください。

また、テーブルを分割してlocation(varchar フィールド?) などをテーブルの外に移動する場合、フィールドは固定幅のままですか? そうでない場合、1 つの可変幅の列を移動することで得られるデータ取得速度の利点は、テーブルに他の可変幅の列が残っている場合に失われますitem_name

(ちなみに、パフォーマンスを向上させるために人々が行うことを検討している最適化の種類については、この回答を参照してください。)

于 2013-08-06T09:15:27.413 に答える