[PHP-users 32240] Re: PHP+MSSQLでJpegデータの登録・表示の方法

kanonbell kanonbell.sky @ gmail.com
2007年 5月 31日 (木) 23:39:44 JST


こんばんは。

> > 画像のようなバイナリデータは、セオリーとしてはDBへの保存はあまり行いません。
> SNSをいじっていますが、画像はDB格納です。
> ファイルを誤って消す、ファイルの中身が一覧で見えてしまうといった問題を回避するのに、
> DBに画像を入れるのは私はいい手だと思っています。

・ファイルを誤って消す
→
ファイルだろうがDBだろうが誤操作で消すリスクはあまり変わらないような。。。
・ファイルの中身が一覧で見えてしまう
→
画像のリンクを直打ちすれば、ログイン後しか閲覧できないはずの画像が
規制できないって意味かな?
それを規制する仕組みは少なくともApacheを利用したシステムではすでに
存在するし、URLでは辿れない階層に置いておけばいいし。
特に書きませんでしたが、画像の登録情報には管理系の情報なども普通に
つけたりするので、削除済みとか一般公開とか会員のみとかステータス
つけておいて、画像の問い合わせの際にこの情報をSELECTして表示の
可否をPHPなりで判断してあげれば済む程度のことですし。

つまり挙げられた点は特にDBのメリットにはなってないような。
ユーザーデータを一箇所で管理できるのはメリットだとは思いますけど。

SNSのようにアクセスが集中するサイトでは、ユーザーの目に見えるシステム
ではなく、負荷分散まで含めた総合的なシステム設計が重要だと思ってました。
Mixiなどは画像専用のサーバが複数存在するようですし。
外部からの閲覧をうまく規制できてないという話も耳にしたので、どっか設計
ミスっちゃったのかなとか中の人も大変だなとか思ったりしますが。

画像までDBに格納すると容量は軽く倍以上行きそうな気もしますし、一日一回
だかのバックアップなどのバッチ処理がきつそうですし、DB多重化してたら
同期もきつそうだし、そもそもできるだけ短時間で処理したいDBの問い合わせ
の時間が増大する訳だし、とか考えちゃいます。
そりゃファイルグループわけたりパーティション使ったりいろいろ工夫はするでしょう
けれど、レコード数が500万とか超えると、テキストオンリーでも割かしきつかったり
してくるもんですし。

私の考えは所詮頭の中で思い描いてるだけなので、実はSNSのような負荷分散が
重要なシステムこそ、BLOBデータを多用したほうがいいとか、むしろファイルのまま
保存しておくのは今は時代遅れとか、なんかそういう趨勢があるんでしょうか。


PHP-users メーリングリストの案内