最近、開発プロセス中にfile storageの問題に直面しました。どのソリューションが最適なのかわからないので、この質問を書くことにしました。私はデータベース管理の経験があまりないので、どのようなヒントも私にとって本当に役に立ちます。
私のアプリケーションプロジェクトには、特定のテーブルと関係のあるいくつかのタイプのファイルがあります。次に例を示します。
...など.
それらすべてのファイル:scan | document | receipt | photo
には異なる拡張子(pdf/jpg/pngなど)があります。
各テーブルに対応するファイルはBLOB
データ型として保存することにしました。 BLOB
を使用するため、データベースのどこかにファイル拡張子を保存する必要があります。
私はいくつかの可能な解決策を検討していました:(デモンストレーションの目的で、単純なテーブルの視覚化を添付します)
ユーザー|請求書| building_photo |トランザクションにはBLOB
またはMEDIUMBLOB
として保存されたファイルが必要ですが、ファイルの拡張子がありません。それを保存する最良の方法は何でしょうか?各テーブルのVARCHAR
列として、または個別のテーブルとして?
各テーブルの拡張ストレージの例:
このソリューションは実装が最も簡単なソリューションです。新しいデータを挿入するときに追加のVARCHAR
を使用すると便利ですが、同じ拡張子のファイルが2つあるため、この情報を繰り返します。
別のテーブルでの拡張ストレージの例:
このソリューションはより最適化されているようですが、新しいデータを挿入する際の管理が少し難しいようです。上記の問題についての提案はありがたいです。
私が検討したもう1つの実装は、すべてのファイルを個別のテーブルに保存するのではなく、file
という名前の1つのテーブルを作成し、これにファイルBLOB
を含め、次に請求書を作成することです。ユーザー|トランザクション|建物などはそのテーブルと関係があります。以下の視覚化:
この場合も、extensionを別のテーブルに保持していますが、file dataも保持しています。すべてのファイルは同じ場所にありますが、大きなテーブルと多くの1対1の関係になります。そのような解決策が理にかなっているなら、私もオプションに感謝しますか、あるいはそのようなことをする別の方法があるでしょうか?
「ユーザーが1つのドキュメントを持っている」(およびその他のドキュメント)は実際にはビジネスルールであり、データルールではなく、将来変更する必要があるかもしれないと思います。したがって、スキーマではなく、トリガー/制約によって実施する必要があります
私はこのようなスキーマで行きます:
USERS -< USER_DOCUMENTS >- FILES
INVOICES -< INVOICE_SCANS >- FILES
BUILDINGS -< BUILDING_PHOTOS >- FILES
TRANSACTIONS -< TRANSACTION_RECEIPTS >- FILES
FILESは次のようになります。
FILES
file_id
content_type
name
data (BLOB)
私たちがそうしている間、「トランザクション」はデータベースでは非常に使い古された用語です。