database - 一意のアイテムに関連付けられている場合、データベースに画像パスを記録する必要がありますか?

Question

私の Web アプリケーションには、インスタンスがイメージ (写真など) を必要とするクラスがいくつかあります。これらの各インスタンスは、1 つのイメージのみを持つことができます。現在、私の実装では、ユーザーが新しいインスタンスを作成するときに、アップロードされたファイルの名前をそのままにして、関連付けられたテーブルの ImageUrl フィールドに記録します。

これは不要な気がします。関連付けられたインスタンスの一意の URL を使用して画像の名前を変更するだけで、それに応じてプログラミング ロジックを実装できます。たとえば、ユーザーの ID が 145 の場合、profilephoto_145 という名前で記録できます。後でユーザーの写真を表示する必要がある場合、必要なのはユーザーの ID だけです。ユーザーが新しいファイルをアップロードした場合、既存のファイルを同じ名前で上書きできます。

各インスタンスに 1 つの関連付けられたイメージがあり、以前のファイルを追跡する必要がないと仮定すると、これは理にかなっているのだろうか。これに対する一般的なアプローチは何ですか？各画像のフル パスを保持し、元の名前を保持する必要がありますか、または ID を使用してこの名前変更ファイルを実装する必要がありますか?

Answer 1

関連付けられたインスタンスの一意の URL を使用して画像の名前を変更するだけで、それに応じてプログラミング ロジックを実装できます。たとえば、ユーザーの ID が 145 の場合、profilephoto_145 という名前で記録できます。

はい、できます。この種の一般的な検索用語は、「密結合」または「結合と結合」です。この概念は、ソフトウェア開発のさまざまな分野に適用されます。

あなたの基本的なアイデアは、常にユーザーごとに 1 つのプロファイル写真を保存し、「ある種のパス」と「profilephoto_」とユーザーの ID を連結して保存するというものです。主な問題は、そのアイデアを変更するには、ソース コードを変更する必要があることです。また、ソース コードの変更には波及効果があります。

一般的な代替方法は、画像ファイルの名前をデータベースに保存することです。この場合、その根底にあるアイデアに対するほとんどの変更は、データベースの更新のみを必要とします。

しばらくの間プログラマーは、人々がalwaysやneverのような言葉を使い始めると、少しうんざりします。十分な時間があれば、ソフトウェアに関して常に使用し、決して使用しないステートメントは常に真実ではないことがわかっているからです。