元スレ【PHP】フレームワーク CakePHP　4ホール目【v1.2】

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

552 = :

mysqlの中に画像を入れるのは馬鹿だろ
そもそもmysqlは画像データを格納するために作っていないから
画像はフォルダに入れて管理した方がいいと
mysql作者が語ってるのに。
そんな自分もかけだしのときはmysqlに画像データ入れてました
管理は楽だけどね。かなりの負荷がかかる。
Bakeとか使う人も素人くさいと思う。

553 = :

>>552
同意。mysqlじゃなく適当なフォルダに画像を突っ込んだ方がいいよ。

555 = :

Bake便利だと思うけどな。
使うのはスキーマ検証時くらいだけど。

556 = :

そもそもBakeの使い方がわからないという。

557 = :

>>552,553
case by caseだとおもうけど

DBでファイルのパス管理してたらそのファイルが消されてたりとか。
かといって参照頻度が高いときはDBに置きたくないしな

さすがにデザインとかで使うような画像は普通に置いとくけどさ

558 = :

>>557
DBに入れておいて、参照されたらキャッシュを作り、そのキャッシュを送信するって方法もあるらしい。
2回目以降は早いし、ファイルが消えても問題ない。

559 = :

たしかにDBにも入れといたほうがバックアップは楽そうだね

560 = :

>>558
それ考えた奴天才じゃね？

561 = :

Cakephpでキャッシュオンにして簡単に実現できそうだ

563 = :

画像格納に強いＤＢならいいけど
mysqlは画像を格納するという目的で設計されてないからね
だから画像をＤＢに入れるのが悪いというのではなく
画像をmysqlに入れるということがナンセンス

564 = :

mysqlは高速が売りだからね
画像格納させたいならoracleとかの方が合理的だと思うよ

565 = :

画像表示のパフォーマンスを考えればLinuxファイルシステムが最強
ＤＢと連携させて管理するのが面倒だけど、そこまで面倒な管理とも思えない
画像はデータの一つだからＤＢ格納がよいという理念なら
htmlもcssも全部ＤＢに入れよということになる

566 = :

データはなんでもかんでもＤＢという流れの人は
ＤＢの持つ性能とバランスをどこまで考えてるの疑問に思う

567 = :

だからあくまでキャッシュ前提の話なんだろ

568 = :

http://dev.mysql.com/doc/refman/4.1/ja/tips.html

通常の Web サーバセットアップを使用する場合は、画像をファイルとして格納する。
言い換えると、データベース内にはファイル参照のみを格納する。この主な理由は、
通常の Web サーバのほうがデータベースコンテンツと比較してファイルのキャッシュに優れているためである。
このため、ファイルを使用したほうがシステムの高速化を容易に図れる。

569 = :

ファイルシステムによるキャッシュ前提なら、DBをバックアップするだけでユー
ザのデータを一括管理できるというメリットしか存在しないと思うけどな。
Railsのときはそうやってて、非常に便利だった。

570 = :

>>554
> コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。

了解です。ありがとうございます。
今回はbootstrap.phpの$controllerPathsでやって、名前の衝突についてはその
都度対処することにしようと思います。

571 = :

A hasMany B
B hasMany C
で
C belongsTo D
みたいなときのリレーションの貼り方が判らないんですが、
そもそも可能なんでしょうか？
（Aを基点にA～Dのテーブルからデータを取ってくる想定）

SQL直書きでは勿論可能ですが。

572 = :

>>571
そこまでしてリレーションに拘るのは返って
生産性を落とす可能性があるから
要はバランスですね
どこからＳＱＬｌ直書きにするかの線引きはね

573 = :

MYSQLだから画像は駄目と硬直的に反応するのは駄目だな

アクセス頻度やキャシュの実装、使い方や状況によって向いてる場合もあろう。

574 = :

画像を表示させるにはフォルダにアップして管理するのが確実みたいですね。
簡単に出来るのなら採用したかったのですが・・・

575 = :

個人情報が含まれる画像だとDBで管理するのが普通でしょ
履歴書の写真とか。

576 = :

ファイルシステムで管理するからと言って、直接見られるところに
置くわけでは無いと思うが。

認証チェック経由でファイルを返すのが普通でしょ。

578 = :

画像格納の話だけど
ファイルパスのみＤＢに突っ込んで画像はファイルシステムから読み出すようにすりゃ良いんじゃないの？
画像データそのものをＤＢに突っ込む必要があるとしたら、
バイナリデータで検索する場合しかなくない？

579 = :

他にもあるな。
例えばＤＢだとデータをまとめて暗号化するようなソリューションがある場合があるが
ファイルシステムに保存するとそういう枠組みから漏れてしまう
まあファイルシステムドライバで暗号化すれば良いだけなんだけど
ドライバ方式とＤＢ方式の差異はパフォーマンスくらいか
それも特定ディレクトリだけ暗号化するようにすれば良いだけか

581 = :

ブラウザ⇔phpは話題にしてないと思うんだけど
php⇔hdd間での画像データのやり取りをどうするかって事だよね

582 = :

>>581
元は前者の話
相談者のスキルが異常に低かったのでなぜか後者の話に移った

583 = :

画像をＤＢで管理てのもファイルシステムで管理てのも
同じくらい面倒だ、ＤＢ画像管理が最高に楽じゃない限り
パフォーマンスのいいファイルシステムになる

584 = :

mysqlを画像に入れた場合のメリットが見えない。。。

585 = :

>>565
同感。

586 = :

>>565
> 画像はデータの一つだからＤＢ格納がよいという理念なら
> htmlもcssも全部ＤＢに入れよということになる

画像はM
htmlやcssはV

DBには入れませんが。。。

587 = :

ユーザの作ったデータ（日々変動する）と、開発者の作ったデータ（基本的に
リリース時で固定）は別物だと思うが。
前者をDBで一元管理できると便利だよ。
まあ抵抗のある人に無理強いするつもりはないし、個々人の自由だと思うけど。

自分はCakePHPでもこれがやれるならやりたいなあ。
何とか実現できないものか。

588 = :

スケールする/しない、管理できる規模/できない規模の話だからな。
条件があえば、DB管理で一元管理でも良いと思う。

この辺を思い出した。
http://neta.ywcafe.net/000774.html
http://blog.livedoor.jp/techblog/archives/64648176.html

590 = :

>>586
ページ上に表示されるような画像はＶだよ
そしてページ上に表示されない画像ならＷＥＢシステムの中に入れておくべきものじゃない
画像でありながらＭになりうるのは、画像検索システムのようなものだけ

591 = :

例えば履歴書の画像データの話が出たけど
それをＷＥＢ上からログインして観覧するようなシステムがあるならＶ
一切使い道が無いならＷＥＢシステム外で保管しておくべきもの
無いと思うけどその画像で画像検索するならＭ

592 = :

>>590
検索対象じゃないとMになれないの？
↓そう読み取れなかったが
http://ja.wikipedia.org/wiki/Model_View_Controller

593 = :

設計にこれが絶対正解ってのはないでしょ。
要件次第だと思うよ。

594 = :

Ｖというのはファイル形式そのもので
ファイルをバイナリーデータに変えたものがＭである

595 = :

>>594
バイナリとかそんなデータ表現は一切問題じゃない

596 = :

Mはデータを扱う仕組み
Vはデータを表示する仕組み
Cはデータを操作する仕組み

画像はデータなのでそのどれでもないと思うが

597 = :

「扱う」と「操作する」の日本語の違いがわからないっす
辞書には
> あつか・う〔あつかふ〕【扱う】
> 道具・機械などを、使ったり操作したりする。取り扱う。
ってあったっす

598 = :

Cは操作限定
Mはデータの出し入れや変換、型決めなど広範囲に扱える

599 = :

MとかVとかなにいうてんねんとおもったら、MVCのことだったのか