私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】フレームワーク CakePHP 4ホール目【v1.2】
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
mysqlの中に画像を入れるのは馬鹿だろ
そもそもmysqlは画像データを格納するために作っていないから
画像はフォルダに入れて管理した方がいいと
mysql作者が語ってるのに。
そんな自分もかけだしのときはmysqlに画像データ入れてました
管理は楽だけどね。かなりの負荷がかかる。
Bakeとか使う人も素人くさいと思う。
そもそもmysqlは画像データを格納するために作っていないから
画像はフォルダに入れて管理した方がいいと
mysql作者が語ってるのに。
そんな自分もかけだしのときはmysqlに画像データ入れてました
管理は楽だけどね。かなりの負荷がかかる。
Bakeとか使う人も素人くさいと思う。
>>552
同意。mysqlじゃなく適当なフォルダに画像を突っ込んだ方がいいよ。
同意。mysqlじゃなく適当なフォルダに画像を突っ込んだ方がいいよ。
>>550
http://book.cakephp.org/ja/view/46/Routes%E3%81%AE%E8%A8%AD%E5%AE%9A
Routes追加すればURL上は階層化されてるように見せることは出来るが、名前の衝突は回避できない。
コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
http://book.cakephp.org/ja/view/46/Routes%E3%81%AE%E8%A8%AD%E5%AE%9A
Routes追加すればURL上は階層化されてるように見せることは出来るが、名前の衝突は回避できない。
コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
>>552,553
case by caseだとおもうけど
DBでファイルのパス管理してたらそのファイルが消されてたりとか。
かといって参照頻度が高いときはDBに置きたくないしな
さすがにデザインとかで使うような画像は普通に置いとくけどさ
case by caseだとおもうけど
DBでファイルのパス管理してたらそのファイルが消されてたりとか。
かといって参照頻度が高いときはDBに置きたくないしな
さすがにデザインとかで使うような画像は普通に置いとくけどさ
>>558
それ考えた奴天才じゃね？
それ考えた奴天才じゃね？
画像格納に強いＤＢならいいけど
mysqlは画像を格納するという目的で設計されてないからね
だから画像をＤＢに入れるのが悪いというのではなく
画像をmysqlに入れるということがナンセンス
mysqlは画像を格納するという目的で設計されてないからね
だから画像をＤＢに入れるのが悪いというのではなく
画像をmysqlに入れるということがナンセンス
mysqlは高速が売りだからね
画像格納させたいならoracleとかの方が合理的だと思うよ
画像格納させたいならoracleとかの方が合理的だと思うよ
画像表示のパフォーマンスを考えればLinuxファイルシステムが最強
ＤＢと連携させて管理するのが面倒だけど、そこまで面倒な管理とも思えない
画像はデータの一つだからＤＢ格納がよいという理念なら
htmlもcssも全部ＤＢに入れよということになる
ＤＢと連携させて管理するのが面倒だけど、そこまで面倒な管理とも思えない
画像はデータの一つだからＤＢ格納がよいという理念なら
htmlもcssも全部ＤＢに入れよということになる
データはなんでもかんでもＤＢという流れの人は
ＤＢの持つ性能とバランスをどこまで考えてるの疑問に思う
ＤＢの持つ性能とバランスをどこまで考えてるの疑問に思う
http://dev.mysql.com/doc/refman/4.1/ja/tips.html
通常の Web サーバセットアップを使用する場合は、画像をファイルとして格納する。
言い換えると、データベース内にはファイル参照のみを格納する。この主な理由は、
通常の Web サーバのほうがデータベースコンテンツと比較してファイルのキャッシュに優れているためである。
このため、ファイルを使用したほうがシステムの高速化を容易に図れる。
通常の Web サーバセットアップを使用する場合は、画像をファイルとして格納する。
言い換えると、データベース内にはファイル参照のみを格納する。この主な理由は、
通常の Web サーバのほうがデータベースコンテンツと比較してファイルのキャッシュに優れているためである。
このため、ファイルを使用したほうがシステムの高速化を容易に図れる。
ファイルシステムによるキャッシュ前提なら、DBをバックアップするだけでユー
ザのデータを一括管理できるというメリットしか存在しないと思うけどな。
Railsのときはそうやってて、非常に便利だった。
ザのデータを一括管理できるというメリットしか存在しないと思うけどな。
Railsのときはそうやってて、非常に便利だった。
>>554
> コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
了解です。ありがとうございます。
今回はbootstrap.phpの$controllerPathsでやって、名前の衝突についてはその
都度対処することにしようと思います。
> コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
了解です。ありがとうございます。
今回はbootstrap.phpの$controllerPathsでやって、名前の衝突についてはその
都度対処することにしようと思います。
A hasMany B
B hasMany C
で
C belongsTo D
みたいなときのリレーションの貼り方が判らないんですが、
そもそも可能なんでしょうか？
（Aを基点にA～Dのテーブルからデータを取ってくる想定）
SQL直書きでは勿論可能ですが。
B hasMany C
で
C belongsTo D
みたいなときのリレーションの貼り方が判らないんですが、
そもそも可能なんでしょうか？
（Aを基点にA～Dのテーブルからデータを取ってくる想定）
SQL直書きでは勿論可能ですが。
MYSQLだから画像は駄目と硬直的に反応するのは駄目だな
アクセス頻度やキャシュの実装、使い方や状況によって向いてる場合もあろう。
アクセス頻度やキャシュの実装、使い方や状況によって向いてる場合もあろう。
画像を表示させるにはフォルダにアップして管理するのが確実みたいですね。
簡単に出来るのなら採用したかったのですが・・・
簡単に出来るのなら採用したかったのですが・・・
ファイルシステムで管理するからと言って、直接見られるところに
置くわけでは無いと思うが。
認証チェック経由でファイルを返すのが普通でしょ。
置くわけでは無いと思うが。
認証チェック経由でファイルを返すのが普通でしょ。
画像格納の話だけど
ファイルパスのみＤＢに突っ込んで画像はファイルシステムから読み出すようにすりゃ良いんじゃないの？
画像データそのものをＤＢに突っ込む必要があるとしたら、
バイナリデータで検索する場合しかなくない？
ファイルパスのみＤＢに突っ込んで画像はファイルシステムから読み出すようにすりゃ良いんじゃないの？
画像データそのものをＤＢに突っ込む必要があるとしたら、
バイナリデータで検索する場合しかなくない？
他にもあるな。
例えばＤＢだとデータをまとめて暗号化するようなソリューションがある場合があるが
ファイルシステムに保存するとそういう枠組みから漏れてしまう
まあファイルシステムドライバで暗号化すれば良いだけなんだけど
ドライバ方式とＤＢ方式の差異はパフォーマンスくらいか
それも特定ディレクトリだけ暗号化するようにすれば良いだけか
例えばＤＢだとデータをまとめて暗号化するようなソリューションがある場合があるが
ファイルシステムに保存するとそういう枠組みから漏れてしまう
まあファイルシステムドライバで暗号化すれば良いだけなんだけど
ドライバ方式とＤＢ方式の差異はパフォーマンスくらいか
それも特定ディレクトリだけ暗号化するようにすれば良いだけか
<?php
// 何かしらの認証チェック...
header("Content-type: ...");
...
readfile( 直接ブラウズできないパスの画像ファイル );
?>
な処理をimgのsrcに指定。
// 何かしらの認証チェック...
header("Content-type: ...");
...
readfile( 直接ブラウズできないパスの画像ファイル );
?>
な処理をimgのsrcに指定。
ブラウザ⇔phpは話題にしてないと思うんだけど
php⇔hdd間での画像データのやり取りをどうするかって事だよね
php⇔hdd間での画像データのやり取りをどうするかって事だよね
画像をＤＢで管理てのもファイルシステムで管理てのも
同じくらい面倒だ、ＤＢ画像管理が最高に楽じゃない限り
パフォーマンスのいいファイルシステムになる
同じくらい面倒だ、ＤＢ画像管理が最高に楽じゃない限り
パフォーマンスのいいファイルシステムになる
>>565
同感。
同感。
ユーザの作ったデータ（日々変動する）と、開発者の作ったデータ（基本的に
リリース時で固定）は別物だと思うが。
前者をDBで一元管理できると便利だよ。
まあ抵抗のある人に無理強いするつもりはないし、個々人の自由だと思うけど。
自分はCakePHPでもこれがやれるならやりたいなあ。
何とか実現できないものか。
リリース時で固定）は別物だと思うが。
前者をDBで一元管理できると便利だよ。
まあ抵抗のある人に無理強いするつもりはないし、個々人の自由だと思うけど。
自分はCakePHPでもこれがやれるならやりたいなあ。
何とか実現できないものか。
スケールする/しない、管理できる規模/できない規模の話だからな。
条件があえば、DB管理で一元管理でも良いと思う。
この辺を思い出した。
http://neta.ywcafe.net/000774.html
http://blog.livedoor.jp/techblog/archives/64648176.html
条件があえば、DB管理で一元管理でも良いと思う。
この辺を思い出した。
http://neta.ywcafe.net/000774.html
http://blog.livedoor.jp/techblog/archives/64648176.html
>>586
ページ上に表示されるような画像はＶだよ
そしてページ上に表示されない画像ならＷＥＢシステムの中に入れておくべきものじゃない
画像でありながらＭになりうるのは、画像検索システムのようなものだけ
ページ上に表示されるような画像はＶだよ
そしてページ上に表示されない画像ならＷＥＢシステムの中に入れておくべきものじゃない
画像でありながらＭになりうるのは、画像検索システムのようなものだけ
例えば履歴書の画像データの話が出たけど
それをＷＥＢ上からログインして観覧するようなシステムがあるならＶ
一切使い道が無いならＷＥＢシステム外で保管しておくべきもの
無いと思うけどその画像で画像検索するならＭ
それをＷＥＢ上からログインして観覧するようなシステムがあるならＶ
一切使い道が無いならＷＥＢシステム外で保管しておくべきもの
無いと思うけどその画像で画像検索するならＭ
Ｖというのはファイル形式そのもので
ファイルをバイナリーデータに変えたものがＭである
ファイルをバイナリーデータに変えたものがＭである
Mはデータを扱う仕組み
Vはデータを表示する仕組み
Cはデータを操作する仕組み
画像はデータなのでそのどれでもないと思うが
Vはデータを表示する仕組み
Cはデータを操作する仕組み
画像はデータなのでそのどれでもないと思うが
「扱う」と「操作する」の日本語の違いがわからないっす
辞書には
> あつか・う〔あつかふ〕【扱う】
> 道具・機械などを、使ったり操作したりする。取り扱う。
ってあったっす
辞書には
> あつか・う〔あつかふ〕【扱う】
> 道具・機械などを、使ったり操作したりする。取り扱う。
ってあったっす
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
php スレッド一覧へ類似してるかもしれないスレッド
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [98%] - 2010/3/18 1:18 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [98%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [98%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 10ホール目【v1.3】 (1001) - [92%] - 2011/2/13 8:32
- 【PHP】フレームワーク CakePHP 14ホール目【v2.1】 (1001) - [92%] - 2012/12/3 19:16
- 【PHP】フレームワーク CakePHP 11ホール目【v1.3】 (1001) - [92%] - 2011/6/30 22:32
- 【PHP】フレームワーク CakePHP 15ホール目【v2.2】 (985) - [92%] - 2013/9/7 8:30
- 【PHP】フレームワーク CakePHP 9ホール目【v1.3】 (1001) - [92%] - 2010/11/1 2:53
- 【PHP】フレームワーク CakePHP 19ホール目【v3.3】 (844) - [90%] - 2023/2/2 14:30
- 【PHP】フレームワーク CakePHP 13ホール目【v2.0】 (995) - [90%] - 2012/4/23 21:16 ○
- 【PHP】フレームワーク CakePHP 17ホール目【v2.4】 (984) - [90%] - 2015/1/10 2:45
- 【PHP】フレームワーク CakePHP 16ホール目【v2.4】 (1001) - [90%] - 2014/3/3 3:00
- 【PHP】フレームワーク CakePHP 8ホール目【1.3】 (1001) - [90%] - 2010/7/22 22:16
- 【PHP】フレームワーク CakePHP 3ホール目【本命】 (1001) - [89%] - 2008/6/19 7:19 ○
- 【PHP】フレームワーク CakePHP 17ホール目【v3α】 (955) - [88%] - 2016/11/15 20:45
トップメニューへ / →のくす牧場書庫について