サイトにアップロードされた単一の画像がFood Item、Dish、Galleryなどの複数のビジネス モジュールで使用される Web サイトを開発しています。ファイル システム上の実際のイメージへの参照を格納
するメインイメージ テーブルがあります。
これで、このテーブルの各レコードは、アイテム、料理、またはギャラリー テーブルで参照できます。
私の質問は、これらすべての参照を単一のテーブルに格納する必要があるか、それとも ItemImage、DishImage などの別のテーブルを維持する必要があるかということです。
単一のテーブルの問題は、このテーブルが高ヒットで攻撃され、最終的に応答時間が長くなるのではないかと心配していることです。複数のテーブルの問題は、ビジネスの最前線でモジュール数が増えるにつれて、テーブルを追加し続ける必要があることです。
自分のサイトにとってパフォーマンスが最優先事項であると言う場合、最善のアプローチは何ですか?
SQL Server 2012、.Net 4.5、MVC 4。
ありがとう
シングルテーブルでのご利用をおすすめします。@Brandon が述べたように、適切にインデックスが作成されていれば、パフォーマンスの問題はないはずです。
また、共通のルート フォルダーからの相対パスのみを保存することをお勧めします (@SpectralGhost の推奨に従って)。共通のルート フォルダーは、運用チームがデータベースを大規模に更新することなく、ファイルの保存場所を変更できる構成設定にすることができます。
1 つのフォルダーに数千のファイルがある場合、ファイル システムのパフォーマンスが問題になることがあります。より多くのツリー構造を得るために、いくつかのレベルのサブフォルダーを作成することをお勧めします。たとえば、ファイル名がABCDE.jpg次のようなパスを使用している場合、ファイルA/B/ABCDE.jpgは数千のサブフォルダーに分割されます。
また、名前の競合を避けるために、アップロードされたファイルのベース ファイル名として GUID などを使用することをお勧めします (ダッシュなしバージョンの GUID を使用して 4 文字を節約します)。元のファイル名が必要な場合は、画像テーブルの別の列に入力してください。幅、高さ、Content-Type ("image/jpeg" など) など、他の画像メタデータを保存することもお勧めします。
キーワードのタグ付けシステムを使用して各画像を分類することは、画像を論理的にグループ化するためのおそらく最良のアイデアです。理論的には、各画像を任意の数のカテゴリ (0 を含む) に割り当てることができます。(tag_id, image_id)これには、タグ リスト テーブルと、ペアを含む別のマッピング テーブルが必要です。
これがインデックスの目的です。それらすべてを1つのテーブルに入れてください。インデックス化されたパフォーマンスがこのシナリオでは問題にならない限り、
1,000,000ページの本があるかどうか考えてみてください。人間としてのあなたにとってさえ、与えられたページ番号を見つけるのにそれほど長くはかからないでしょう...ページが整然としている限り。そして、1億ページの本からページを見つけるまでの時間の差は、実際にはそれほど長くはなりません。
データについて複雑なレポートを作成している場合は異なる場合がありますが、これは単なるルックアップテーブルです。