SQLアンチパターン11章メモ

11章 ファントムファイル(幻のファイル)

11.1 目的:画像をはじめとする大容量メディアファイルを格納する

11.2 アンチパターン:物理ファイルの使用を必須と思い込む

画像データをどうやって保存しておくのか？
・問題は実際にDBにBLOG型として保存するか、外部のファイルシステムに保存しDBにはファイルパスを VARCHAR型として保存するか
・大多数は外部のファイルシステムに保存する
・どちらもメリット、デメリットがある

11.2.1 ファイルの削除時における問題

・画像がDBの外に保存してある場合、DBで画像のファイルパスを削除しても、実際の画像までは削除されない。
・ファイルパスが削除されたら、参照先の画像も削除されるようにアプリを設計する必要がある
・でないと、「孤児」となった画像が蓄積されていってしまう

11.2.2 トランザクション分離の問題

・通常、削除や更新はトランザクション(関連する処理)が成功して、結果が確定するまで変更は他のクライアントからはわからない
・だがDBが外部にある場合、クライアントはその変更を見ることができる。
・頻度はあまり高くない

11.2.3 ロールバック時における問題

・DELETE文をrollbackしようとしてもファイルを削除してしまっていれば元に戻せない

11.2.4 データベースのバックアップツール使用時における問題

・DB製品は、使用中のデータベースのバックアップを支援するためのクライアントツールがある
・ただし、バックアップに外部のファイルシステムは対象外
・そのためDB用のバックアップとファイルシステム用のバックアップの二種類が必要
・DB外部ファイルの同期はどうするのか

11.2.5 SQL アクセス権限使用時における問題

・DB内のテーブルや列に対してのアクセス権限は管理されているけど、外部ファイルに対してSQLでは参照できない

11.2.6 ファイルはSQLデータ型ではない

・DBは格納された文字列が正しいパスかどうかは検証できない
・指定されたパスにファイルが存在しているかは検証できない
・ファイル名の変更、ファイルの移動、削除が行われてもDB内のパスは自動的に変更されない
・文字列をパス名として保証するにはアプリ側に依存することになる

11.3 アンチパターンの見つけ方

設計をしたエンジニアがいた場合質問をする
・データバックアップとリストアの手順は確立されているか。。。
・画像が増える一方になるのではなく、不要になったときにシステムから削除されるような仕組み になっているか。。。
・画像ファイルへのアクセス権を持っているアプリケーションユーザーは誰か。。。
・画像に対する変更をキャンセルできるか。。。

11.4 アンチパターンを用いてもよい場合

・DBの容量を減らせる
・DBのバックアップが手軽になり、バックアップデータも軽量になる
・画像が外部にあるとプレビューや編集が容易になる

11.5 解決策:必要に応じて BLOB 型を採用する

・どんなDBを設計するのかを十分に検討する必要がある