Web アプリケーションを作成していて、ユーザーがファイルをアップロードできるサイトの領域がいくつかあります。これに対する私の基本的な作業方法は、実際のファイルをサーバーに保存し、保存されたファイル名を関連するレコードに接続するデータベース テーブルを用意することです。
私の質問は次のとおりです。ファイルの「タイプ」ごとに異なるテーブルが必要ですか? また、ファイルはサーバー上のコンテキストに関連する場所に保存する必要がありますか、それともすべてまとめて保存する必要がありますか?
例: ユーザーのプロフィール写真、求人応募履歴書、CMS ページ上の関連ドキュメントなど。
あなたの例から、2つの異なるものに関連付けることができるファイルがあるため、2つのテーブルの引数があります。
これらを 1 つのテーブルに入れる場合 (そして、ユーザーが複数の写真または履歴書を持つことを許可したい場合)、files->users と files->cms_pages を関連付けるために 2 つのリンク テーブルが必要です。おそらく、これは HABTM 関係を暗示していますが、これは正しくなく、一貫性のないデータを許しています。
2 つのテーブルを使用するアプローチは、ややクリーンで、ファイルを単純な属しているエンティティの適切なタイプに関連付けることのみを許可します。
しかし、ファイルタイプごとに異なるタイプのメタデータを保存する必要がない限り、この質問に対する「正しい」答えはないと思います。
また、各ファイルの MIME タイプを保存するか、計算できるようにして、正しい HTTP ヘッダーを使用してブラウザに正しく提供できるようにしてください。
あなたが言ったことから、ランダムな（UUIDまたはその他の）ファイル名を持つファイルを1か所に保存するだけです。次に、「添付ファイル」テーブルまたはすべての外部ファイルへの参照を含む何かを作成します。このテーブルには、そのファイルのメタデータも含まれているため、ファイルの種類 (画像、履歴書など) なども含まれます。
ただし、使用している FS によっては、1 つのディレクトリ内のファイル数に厳しい制限がある場合があります。
さまざまなファイルをさまざまな場所に保存する理由はさまざまです。
まず、1 つのディレクトリ内のファイル数の制限が考慮される場合があります。
次に、セキュリティが問題になる可能性があります。公開できるもの (プロフィール写真など) と公開できないもの (CV など) がある場合、それらを別のディレクトリに配置すると管理が容易になります。
第 3 に、ファイルが分割されている場合、たとえばファイル エクスプローラーで参照したり、バックアップを管理したり、ファイル ストレージを複数の場所に分割するようにアプリケーションを変更したりすると、単純な管理タスクがより簡単になります。
ファイル名の競合の問題もありますが、(たとえば) データベース ID フィールドに一致するようにすべての名前を変更した場合、これは問題になりません。
しかし、結局のところ、それはおそらくボリュームとあなた自身の好みに依存します.
ファイルの種類ごとに別のテーブルが適切になるのは、ファイルの種類ごとに他のメタデータ (したがって、追加の列) を保存する場合のみです。各ファイル タイプのテーブルに同じ列のみが含まれる場合 (例: filename、filetype、dateuploaded など)、それらすべてを 1 つのテーブルに配置するのが理にかなっています。