こんにちは、
私はアプリケーションを設計していますが、この問題に頭を悩ませているようには見えません。私のアプリケーションには、会社、プロフィール、マシンなど、さまざまな種類の写真があり、たくさんの写真が期待されています。さて、さまざまな種類の写真があるので、Djangoで「pictures」という基本クラスを作成し、そこからすべてのサブクラスを作成することを考えていました。これにより、データベースにn個のテーブルが作成されます。したがって、すべての写真を含む1つの巨大なテーブルがなく、特定のタイプの写真が必要な場合はカテゴリテーブルでJOINSを実行する必要があるため、クエリが高速になります。
これを行うには、Djangoで汎用外部キーを使用する必要があります。それは良い習慣ですか？私のデザインは良い習慣ですか？Generic Foreign Keysはそれほど良いアイデアではないと言われました...なぜですか？
ありがとう！
編集：画像自体はテーブルに保存せず、AWS S3バケット内のパスのみを保存します！
画像をデータベースに保存する必要がありますか? 多くの場合、イメージをデータベースではなくファイルシステムに保存することで、効率を大幅に向上させることができます。
イメージをファイルシステムに保存すると、Web サーバー、または Amazon S3 やコンテンツ配信ネットワーク、memcached などのクラウド ホストから直接提供できます。
独自のデータベースでは、保存するのに適した情報 (IMHO) は、検索可能なファイル名 (ユーザーがその方法で検索する場合)、ピクセル寸法 (サイズで検索する場合、または画像の高さと幅を提供する場合) などの画像に関するメタデータです。 HTML で)、mime コンテンツ タイプ (役に立つ場合) など。
さまざまな種類の画像の説明については、各種類についてどのような種類の異なる情報を保存したいかによって異なります。
画像の種類は基本的に同じですか？[種類とは、Company、Profile、Machine などのようなものです] もしそうなら、列挙型フィールドを使用して、それらすべて (つまり、メタデータ) に対して 1 つのテーブルを使用します。データベースによっては、"company"、"profile" などの文字列名、または会社の場合は 1、プロファイルの場合は 2 などの int 定数を使用してこれを行うことができます。Django には継承を行う方法がいくつかあります。 . このパターン名は、Single Table Inheritance (STI) です。Django はこれを正確にサポートしていないと思いますが、検索すれば、実装方法の適切な範囲にたどり着くことができます。
あなたのイメージの種類は本質的に異なりますか? 画像のデータの種類が大きく異なる場合は、別のテーブルを使用してください。
私の知る限り、インデックスを持つ 1 つのテーブルを使用する場合と個別のテーブルを使用する場合の速度の違いは似ているはずです。どちらの場合も、画像行の範囲を見つけるための要求ごとに基本的に 1 つのルックアップがあるためです。確実にベンチマークできます。
ちょっとしたコードを書く前に、Facebook がこれをどのように達成したかを読んでください。これは素晴らしい概要です。