私は常にジレンマを抱えています。レコードには、そのレコードの画像がある場合はtrue、ない場合はfalseの列画像（tinyint）を使用できます。
また、その情報をデータベースに入れることができず、コードでディスクファイルシステムを「スヌープ」してイメージが存在するかどうかを確認します。
もちろん、どちらも同じ結果になります。データベースにあるということは、ディスク上の実際のイメージとは別にイメージの状態を維持することを意味し、プログラミングが難しく、エラーが発生しやすくなります（データベースでは、レコードは列イメージに当てはまります）。
ですから、普段はディスクチェックを使っています。しかし、それは私に起こりました、多分これはディスクアクセスに厳しいペナルティを持っています。私はデータベースチェックがより速くなければならないことを知っています、とにかくデータベースからレコードを取得する必要があります。しかし、ファイルシステムを使用して画像を探しているのは、私が思いついたのと同じくらい悪いですか？
データベースに保存するための長所：
ディスクに保存するだけの長所はわかりません。「単一の責任の場所」を持つパターンを使用します。これは、コード内の1つの場所のみが画像の保存、更新、削除を行うことを意味します。この場所で、ファイルとデータベースを更新します。このようにすると、エラーが発生しにくくなります。
逆に言えば、これによりアプリケーションでエラーが発生しやすくなる場合は、アーキテクチャを確認する必要があります。
私の意見では、ディスクのチェックは無駄であり、少し悪い習慣です。DBはこれを保持する必要があります。理由は次のとおりです。
とにかくファイルの名前を維持するので、列を維持することはそれほど大騒ぎするべきではありませんよね？したがって、ファイル名が更新されると、この列もそれに応じて更新される必要があります。
画像が存在する可能性が高いですか、それとも存在しない可能性が高いですか？ファイルが存在するかどうかを確認している場合は、常にファイルを使用しますか？
両方の答えが「はい」の場合は、必ずディスクを使用してください。圧倒的な大部分の時間に存在すると信じる理由がある場合は@file、FALSEリターンを使用して処理します（特にfile_existsにはクロスプラットフォームの実装の問題がある可能性があるため）。これは十分な実践以上のものだと思います。
そうでない場合は、プログラムフローを確認する必要があります。
データベースに質問する-ファイルは存在しますか？
ファイルの使用を計画している場合は、DBがそのファイルを示しているかどうかを確認する必要があります。つまり、DBを使用して最適化できるのは、ファイル自体が不要な場合のみです。