スレッドメモ

◆ [pgsql-jp] 画像データベースの作成。

[30568] キャスター　マイルド (7/24)

バイナリデータのデータベース化を計ろうと考えるとき、直接PostgreSQLに格納するか、データは別の所に保存し、その情報（ファイル名やサイズなど）のみをデータベースに放り込むか、どちらが良いでしょうか？

[30573] Tatsuo Ishii (7/24)

large objectを使った方が管理やアプリケーションの手間が減っていいのですが，単純にファイルに置く場合に比べると容量が増えてしまいます．

[30576] Tanaka-Qtaro-Yasuhiro (7/24)

このメーリングリストの以下のメールから始まるスレッドが参考になると思います。

[pgsql-jp 21110] ラージオブジェクトを使った画像管理
http://ml.postgresql.jp/pgsql-jp-old/pgsql-jp/2001May/threads.html#00167

[30577] 松嶋祥文 (7/24)

私は Large Object 派(?) ですが、ファイルで管理するのを避けるのは以下の理由です。

1. Permission 関係が面倒
2. ファイル名の重複回避の手段を考えるのが面倒
3. バックアップが DB と別管理になるのが面倒
4. 環境移行／同一環境作成の際に面倒
5. 上記のテストが面倒
6. ファイルシステム(ext2など)の特性を考えるのが面倒

[30587] Hirokazu Aoyama (7/25)

そういう不整合状態がシステムの仕様上クリティカルである場合は、[pgsql-jp 21164]で五十川さんがご指摘されていたように、アトミックな操作を行なえるよう、ファイル操作を用いずにDB内に閉じた操作がより好ましいと思います。

[30588] Jun Kitamura (7/25)

「ファイルの実体」と「データベース内のファイル格納場所情報」の整合が取れないような状態にするのは(私の観点からは)許されざるべきことであり、それを「仕様」としてしまうのは変です。ファイルのコピーと、データベースへのタプル挿入、の 2つを別々のトランザクションと捉える設計が間違っているだけだと思います。

[30592] Hirokazu Aoyama (7/25)

これは一見するとトランザクションのように見えますが、実際には、以下のような問題があります。

(1) ファイル処理を失敗した場合の「ロールバック」処理が本当にうまくいくのか？

(2) ファイルを削除してからCOMMITを行うまでの間にDBMSとクライアントとの通信が切れたりシグナルを受信したりして強制的にロールバックしてしまうケースも考えられる。この場合は、DB内にレコードは残っているが、ファイルは存在しないという形になる。