トップページ⇒php
1001コメント282KB

【PHP】フレームワークについて語るスレ10【総合】

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001nobodyさん2008/08/24(日) 21:43:37ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1202521438/
0885nobodyさん2008/12/16(火) 22:20:21ID:???
変換されちゃった。
下の&は＆amp;な。
0886nobodyさん2008/12/16(火) 23:07:56ID:???
>>877
> >>869
> ndex.cgi?name=foo&passwd=baが読みやすいというのは
> プログラマー的な視点だと思う。
> しかもpasswd筒抜けやんｗ
> 初心者は
> hoge.com/poge/categoryId/100
> で区切られてる方がわかりやすい
name=fooなら、nameとfooが対応してるのが誰でも分かるだろう。&ってANDが文章をつなぐ単語って小学生でも知ってる。
/で区切るとどこまでがURLでどこからがクエリパラメータか分からない。
http://example.com/news/name/10で、nameがアクションクラス名なのかクエリパラメータのキー名なのか、誰にも分からない。
0887nobodyさん2008/12/16(火) 23:59:17ID:???
まあ、ちっちゃな利点を上げてみると、
http://example.com/news/name/10.html というURLだったとして、
動的に出力されているのか静的に置かれているのかも誰にもわからない。
そしてそれは、いずれ静的なファイルに置き換えてもリンクを変更する必要がない。
こういう事をいうと You Aren't Gonna Need It とか言われるのかも知れないけど、あくまで一利点として。
0888nobodyさん2008/12/17(水) 01:16:44ID:???
>>886
＞name=fooなら、nameとfooが対応してるのが誰でも分かるだろう
おまえがプログラマだからだろ？
初めてＰＣさわったとき、ＵＲＬの意味が全く不明でした
ＵＲＬつかってデータ飛ばしてるということ知らなかったし
だからＵＲＬは/区切りの方が単純明快でわかりやすい
わかりやすいといっても素人的観点からのわかりやすいという意味だよ
nameがわからないとかはプログラマ視点やろ
0889nobodyさん2008/12/17(水) 01:21:40ID:???
クエリは小さいサイトならわかるかもしれんけど
yahooとかのクエリて
どんだけパラメータはいってんねん、
これ何の変数なん？てくらい
長いで
あそこまで長いパラメータなら区切てのクエリでも
変わらんわな。ロボットも長いＵＲＬ拾わんやろうし
0890nobodyさん2008/12/17(水) 01:24:05ID:???
残念ながらそれはお前が低脳なだけだ
0891nobodyさん2008/12/17(水) 06:45:41ID:???
本来ディレクトリを示す記号をほかの事に使ってるというのがまず気持ち悪い
いっこ削って上の階層にいけないようならスラッシュ区切りにする意味ないとおもうわー
0892nobodyさん2008/12/17(水) 08:45:42ID:???
普通にウェブをみる分にはURLなんて意識する必要ないんだよ。リンクをクリックするだけ、ブックマークするだけなんだから、URLを見る必要はない。
携帯のブラウザなんかだと、URLが確認出来なかったりするぐらいだから。
あえてURLを見ようと思った時に、/区切りでパラメータとURLが一体になってる方がわかりやすいか、パラメータがハッキリ区別されてる方がわかりやすいか。当然、後者。
/区切りが有効なのは、昔のSEO対策ぐらいなもの。それ以外は開発者の自己満足。
0893nobodyさん2008/12/17(水) 11:19:55ID:???
でも wikipedia.org/WebProg が wikipedia.org/index.cgi?q=WebProg だったら面倒だろ。要は使いどこ
0894nobodyさん2008/12/17(水) 19:49:31ID:???
パラメータが多いときは普通両方合わせて使うだろ
0895nobodyさん2008/12/17(水) 20:58:37ID:???
>>886
URLで何を表してるか、なんじゃないかなぁ。。

そこで出てるニュースの例なら

news.php&year=2009&mon=12&day=17

よりも

news/2009/12/17

のほうが、意味あいとして分かりやすいと思うけど。
0896nobodyさん2008/12/18(木) 01:49:52ID:???
別に http://example.com/news.cgi?2008&12&18 ってやったっていい。
URL本体とクエリストリングは本来機能が違う物なのに、わざわざごちゃ混ぜにしてるところに問題がある。
しかも、mod_rewriteに頼らないと行けない。
画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。
手間がかかるくせにメリットが少ないから、/区切りにするのはくだらないと思う。
0897nobodyさん2008/12/18(木) 01:54:25ID:???
> しかも、mod_rewriteに頼らないと行けない。

そんなことはない
0898nobodyさん2008/12/18(木) 02:07:07ID:???
どうやるわけ？
0899nobodyさん2008/12/18(木) 02:09:31ID:???
問題は、要素によってpathinfoとクエリを使い分けたいのに、
ヘルパを通すと一括してpathinfoにされることではないか。
0900nobodyさん2008/12/18(木) 02:10:07ID:???
PATH_INFOだな。
例えばnucleusのfancyモードもmod_rewirte使ってない。
0901nobodyさん2008/12/18(木) 02:16:40ID:???
もう好みの問題だな
0902nobodyさん2008/12/18(木) 02:16:47ID:???
それだとApacheに別の設定を加えないと行けないじゃん。
0903nobodyさん2008/12/18(木) 02:20:07ID:???
俺も好みだと思うよ。けど、記号が少ない分、見た目が良いぐらいしかメリットないじゃん。後はどこまで効果があるか分からないSEO対策か。
開発効率落としてまでやる事じゃないと思うけど、それがこだわりだって言われれば、そりゃ勝手ではあると思う。
0904nobodyさん2008/12/18(木) 02:21:36ID:???
>>902
.htaccessで済む。まぁ許可されていればの話しだが。

> 画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。

フレームワーク使っているのなら、わざわざクエリストリングを直接弄るようなことはないだろうに。
>>901に同意。俺は/区切りの方がスッキリする。
0905nobodyさん2008/12/18(木) 02:31:24ID:???
意味のない区切り出なければ/で区切るのが自分の中での最適解
0906nobodyさん2008/12/18(木) 02:40:08ID:???
画像のサムネイルをキャッシュする場合は/区切りだとフェイクできるな
画像加工済みであれば、ファイルが存在するからそれを返して
まだであれば、加工して保存後それを返すって感じで
0907nobodyさん2008/12/18(木) 02:42:33ID:???
mod_rewriteだって、.htaccessで出来るだろ。
例えばhttp://example.com/news/2008/12/18だって、年月日の順で引数が渡されることを把握してなければいけない。
こんなのすごくくだらない。
func(2008,12,18)ってプロトタイプよりfunc(array(year=>2008,mon=>12,day=>18))の方がメンテナンス性の高いプロトタイプだよ。
0908nobodyさん2008/12/18(木) 02:53:47ID:???
symfonyだと名前を付けられるよ
順番変更になってもルーティング弄れば全部反映されるし
ただパフォーマンス的にコストがちょっとかかるけど
0909nobodyさん2008/12/18(木) 03:21:10ID:???
>>907
いや、>>904では、「mod_rewrite必須。でなければ、Apache別設定必要」という意見に答えたまで。

> こんなのすごくくだらない。

だからくだらないかどうかは好みの問題でいいんじゃね。
メンテナンス性も大事なのはわかるが、糖衣構文と同じで慣れもあるし。
09108952008/12/18(木) 04:24:35ID:???
>>896

うーん。。そういうのが>>877が言ってる
プログラマ的視点ってことじゃないかなぁ。。

URLは場所やリソースを表すって意味じゃ
階層的にで表現できるものは/区切りがキレイな感じがする。

year=2008&month=12&day=18
ならまだしも
month=12&year=2008&day=18
って、なんか気持ち悪くない？

RESTにちょっと興味あるからかも知れんけどｗ
0911nobodyさん2008/12/18(木) 07:12:11ID:???
ようやくrestという単語が

ここでクエリクエリ言ってる人はrestを一通り勉強した上で言っているのかどうか気になる

一昔前の感覚から抜けきれないプログラマさんとしか思えない
0912nobodyさん2008/12/18(木) 07:16:33ID:???
>>910
それはRESTと全く関係ないでしょう

>>911
RESTだからpathinfoってのは違うよ。
RESTだってquerystringで基本処理することは問題ない。

なにか、910も911もRESTをちゃんと勉強してから、有意義なコメントを求む。
0913nobodyさん2008/12/18(木) 09:15:43ID:???
以下、RESTバスワード問題についてに議論が移ります。
てか、本当に話題なんでもいいのなｗ
0914nobodyさん2008/12/18(木) 10:24:50ID:???
ZFって速いん？
低機能だから速そうではあるけど
0915nobodyさん2008/12/18(木) 10:25:11ID:???
RESTfulにするなら、階層構造を使うべきところは階層を、
そうでないところはクエリ文字列をつかうべきだよね。

なんかお前ら、どっちかしか使わないみたいな二元論にハマってないか？
使い分けてナンボでしょこういうのは。

http://.../news/08/12/18?query=money

なんて分かりやすいじゃないか。
0916nobodyさん2008/12/18(木) 10:32:53ID:???
大体、
・ステートレス
・PUT、DELETEを使え
って時点で、RESTfulにこだわってたらWEB APIは作れても普通のWEBアプリは無理だろ。
大体、RESTって認証はどうするんだ？ステートレスってぶっちゃけGET以外は非現実的じゃないの？
参考にするのはいいが、どうせRESTfulにはならないんだし、URLも違う視点でいいよね。
0917nobodyさん2008/12/18(木) 10:37:23ID:???
http://sourceforge.jp/magazine/08/12/08/0347234
最適化したブートストラップファイル「Yiilite」を利用時、1秒当たり最大427のクエリを処理できるという。

サーバのスペックも書かずにこの数字って
何か意味あんのか？？？
0918nobodyさん2008/12/18(木) 10:53:23ID:???
>>916
REST的概念にしたがってコードを書くことをRESTfulって言わないの？
RoRとかRESTful謳ってるけど？
>>917
select 1;
0919nobodyさん2008/12/18(木) 12:00:09ID:???
>>918
RoRのRESTは
PUT・DELETE → JavaScriptで疑似リンク作成（POSTだけどhiddenでメソッド種別埋め込み、サーバ側で処理）
ステートレス → 棚上げ？

フレームワークレベルで頑張ってるみたいね。
そこまでやるんならURL（URI）も頑張ってRESTfulにすればいいんじゃね？
↓こんなのもあったｗ
http://www.nicovideo.jp/watch/sm3823700
0920nobodyさん2008/12/18(木) 12:09:43ID:???
>>919
scaffoldはそうなってんじゃね？
Ruby詳しくないから深く突っ込めないけど。
0921nobodyさん2008/12/18(木) 12:11:30ID:???
CRUDと混同してたorz
0922nobodyさん2008/12/18(木) 16:01:51ID:???
>>910
海外じゃじゃ12/18/2008って日付表記もメジャーだよ。12や18が何を意味するのか、コードの中を見ないと判断つかない。
0923nobodyさん2008/12/18(木) 18:38:36ID:???
でもURLでその順で表記することはまずありえないよなｗ
2008年のなかの12月のなかの18日〜みたいに書かないと階層化になんないし
0924nobodyさん2008/12/18(木) 20:21:57ID:???
yiiってpdoベースだけど、pdoって何かバグあったよね？
0925nobodyさん2008/12/18(木) 21:13:55ID:aX375k2z
ないよ
0926nobodyさん2008/12/18(木) 21:50:37ID:???
あったよ
0927nobodyさん2008/12/18(木) 21:52:38ID:???
なんだっけ
0928nobodyさん2008/12/18(木) 21:55:14ID:???
ほら、あれだ
0929nobodyさん2008/12/18(木) 21:56:58ID:???
タグ理解ｗｗｗ
0930nobodyさん2008/12/18(木) 22:15:38ID:???
pdo 不具合 に一致する日本語のページ 約 8,080

何この糞ライブラリ
0931nobodyさん2008/12/18(木) 23:09:41ID:???
ここは呆け老人の巣か？ｗ

てのはいいとして、>>930
GoogleかYahooか知らんが、

　PDO 不具合 (7,850) / PDO (346,000) ・・・ 2.27%
　PEAR DB 不具合 (9,470) / PEAR DB (115,000) ・・・ 8.23%
　PEAR MDB2 不具合 (3,440) / PEAR MDB2 (45,000) ・・・ 7.64%
　
　JDBC 不具合 (39,700) / JDBC (161,000) ・・・ 24.65%
　ODBC 不具合 (37,400) / ODBC (411,000) ・・・ 9.10%

　（上記全てGoogle 日本語ページ）

むしろ優秀じゃね？そうでなくても、ただ単に普及率や話題性が数字で出てるだけじゃねーかと。
JDBCがなんか笑えるけどなｗｗ
0932nobodyさん2008/12/19(金) 00:29:20ID:???
まぁ、不具合の話題にPDOその他の話題が含まれてる、みたいな
全く関係ないヤツが殆どなんだけどな
0933nobodyさん2008/12/19(金) 01:19:55ID:???
まぁ確かに不具合もあるだろうよ。
今度PHPとSQL Serverなんだが、PDO_DBLIBの完成度とか微妙そうだ。
今からgkbrだ。
0934nobodyさん2008/12/19(金) 12:14:17ID:???
クエリて基本的にＰＯＳＴで飛ばしたときのパラメータデータと認識してるのだが。。。
ＧＥＴで飛ばした場合はクエリとはいわない
0935nobodyさん2008/12/19(金) 12:20:32ID:???
何その思い込み
0936nobodyさん2008/12/19(金) 12:24:34ID:???
これはまた斬新な説だな
09379342008/12/19(金) 12:29:07ID:???
俺の場合はソケットプログラミング的発想だからな
09389342008/12/19(金) 12:52:28ID:???
なんだか俺の間違いくさいからクエリの話はもう終わりにしよう
0939nobodyさん2008/12/19(金) 13:53:30ID:???
>>938
そもそもそれの事をクエリと呼ぶのが間違い。
ちゃんとクエリ文字列とかクエリストリングと言いなちゃい。
0940nobodyさん2008/12/19(金) 21:43:46ID:???
アクセス解析の効率はURL決定に影響しないのじゃろか
0941nobodyさん2008/12/19(金) 21:47:53ID:???
確かに、クエリパラメータが順不同になる様な状態なら、アクセス解析の効率は落ちそうだねえ。
でもそれが設計にそれほどの影響を与えるかどうかは・・・正直そこまで気にしてらんねｗとか
0942nobodyさん2008/12/20(土) 03:11:01ID:???
順不同だと効率が落ちる？頭イカれてるのですか
0943nobodyさん2008/12/20(土) 03:25:26ID:???
Apacheのログ解析みたいな処理の場合、頭から順にパス区切りでページが特定できる方が、
効率よさそうな気はするが。
list.php?q=hoge&page=2&cate=3とかなってるより、
list/cate/3?page=2&q=hoge の方が楽そうだなーとかは感じる。
実際はどうかわからんけどな。
0944nobodyさん2008/12/20(土) 03:45:04ID:???
気がする（笑）
0945nobodyさん2008/12/20(土) 04:23:39ID:???
symfony以外のカスFWってエラー時のスタックトレース画面がショボいよねｗ
0946nobodyさん2008/12/20(土) 11:09:04ID:???
>>943
気がするではなく自明だろとか書くと、仮に大嘘でもそのまま飲み込む奴は出てくるんだけどな
書き方としてはその方が2ch向きかな
0947nobodyさん2008/12/20(土) 11:41:11ID:???
>>946
それは>945見たい書き込みのことか？
0948nobodyさん2008/12/20(土) 18:52:04ID:VXNsKNQ0
アクセス解析くらい自作しろよ。効率化とかしょぼい解析つかってるのかな
0949nobodyさん2008/12/20(土) 19:40:14ID:???
>>948
車輪の再発明
0950nobodyさん2008/12/20(土) 23:49:25ID:???
自作(笑)
0951nobodyさん2008/12/21(日) 00:10:34ID:???
アクセス解析を作るとしたら、
Google Analyticsでは対応できなくなったときだな。

アクセス数が少ないやつがアクセス解析を作ると
一人ひとりのアクセスしたページの履歴を見れるとか
わけのわからない機能を作りそうｗ
0952nobodyさん2008/12/21(日) 00:20:56ID:???
アクセス解析ですが、自分のサイト内を移動するユーザーの様子は、
リファラー情報をDBに保存して集計していますか？
0953nobodyさん2008/12/21(日) 00:28:37ID:???
GoogleでiGoogleアカウント作ると検索履歴をすべて保存される。
しかも頑張らないと消せないぜ。
0954nobodyさん2008/12/21(日) 05:35:57ID:???
IPアドレスごとの検索履歴なら
昔から永久保存してるよ
0955nobodyさん2008/12/21(日) 22:53:57ID:V1c8MsfO
アクセス解析自作とかどんだけ
0956nobodyさん2008/12/21(日) 23:34:59ID:???
cgi?password=

コードが全てを物語ってるじゃないか。
相手にする価値無いだろ。
0957nobodyさん2008/12/21(日) 23:36:57ID:???
>>956
何の話?
0958nobodyさん2008/12/22(月) 02:31:00ID:???
どこがフレームワークの話？
0959nobodyさん2008/12/22(月) 06:22:15ID:UnYE/VzJ
CakePHPのアソシエーションでInner Joinを利用してレスポンス速度を向上
http://blog.katsuma.tv/2008/12/inner_join_on_cakephp.html

インナージョインとレフトジョインて別物だし、
簡単にテレコにできるもんじゃないよね？
これってどういうことなん？
0960nobodyさん2008/12/22(月) 06:49:37ID:???
ってかレフトジョインてそんなに遅くなるの？
今作成してるサイト、テーブルいくつもレフトジョインしてるんだが・・・
0961nobodyさん2008/12/22(月) 08:10:23ID:???
そんなもんRDMS依存だろ。
0962nobodyさん2008/12/22(月) 08:19:55ID:???
程度の違いはあれ、LEFT の方が遅い。
それより、CakeのモデルでINNERにできるところをLEFTにしてるとしたら
（たぶんそういうことなんだろうけど）ちょいとお粗末すぎる希ガス
0963nobodyさん2008/12/22(月) 08:23:10ID:???
レフトジョイン→インナージョインにして問題ないのって
接続対象が0にならない場合だけでしょ
タグっぽいの駄目だし使いどころなさそう
0964nobodyさん2008/12/22(月) 08:29:38ID:???
>>963
LEFTじゃなきゃだめなところをINNERにして動作に異常がないわけはないんで、
普通にINNERでよいところをLEFTにしてるかどうかが問題なんじゃない？
0965nobodyさん2008/12/22(月) 08:37:43ID:???
ナルホド
0966nobodyさん2008/12/22(月) 10:10:57ID:???
>>959
NULLが出来るクエリなんてキモチワリーってことなんじゃない？
ちゃんと設計してあればLEFT JOINなんてそんな使わないよ。
0967nobodyさん2008/12/22(月) 10:33:27ID:???
解析プログラムはアーチンで
１日で3Gくらいのログファイルを想定してた
ディレクトリ毎にアクセス状況を表示出来るので、そちらのがディレクション側にも理解し易いかなとか
GETで渡ったパラメータも項目別に出るけど、ページ検索だか訳判らん表現に

まぁ機能以外のつまらん理由で仕様が決まる事もあるねー
以上の話題にならんかったな
0968nobodyさん2008/12/22(月) 10:38:37ID:???
スレチかもだけど、流れ乗じて聞いてみる。
LEFT JOINの方が遅いとか、その辺の知識が弱くて困ってるんだけど、
その辺を学ぶのにいい情報源ないですか？
CRUDなSQLは一通りかけるけど、JOINなんかは解説サイトを鵜呑みにして、
とりあえず出来てるレベル。
もうちょっとしっかりとした知識を身につけたいところ。
0969nobodyさん2008/12/22(月) 10:45:12ID:???
>>968
LEFT JOINの方が遅いという一般的な事象については、RDBMSの内部動作の基本を
理解していれば、自明。RDBMSの基礎理論を扱ったドキュメントになら書いてあるでしょう。
RDBMSのドキュメントに結合の最適化やINDEXの使われ方、処理フローに
ついて書いてあることもある。そこは運だな。
0970nobodyさん2008/12/22(月) 11:10:29ID:???
>>969
難しいな。
0971nobodyさん2008/12/22(月) 11:19:09ID:???
あえてお勧めの書籍やどのRDBMSのドキュメントかなどを記さないスパルタな>>969
0972nobodyさん2008/12/22(月) 11:34:07ID:???
うーん、答えるのも難しいね
ttp://www.inter-office.co.jp/contents/157/
たとえば、ここにベンチ出てるんだけど、前のアイテムでLEFT JOINして性能が1/3になってるという話。
ただ、これは一般的に1/3になるというのではなく、LEFT JOINするときにどのくらいNullになるレコード
があるかによって速度は全然違うから、完全な比較はできない。
そもそも、使い路の違うものを速度比較っていう考え方自体がないんだよね。

0973nobodyさん2008/12/22(月) 11:44:52ID:???
そりゃ1枚のテーブルに入ってる方が早いだろうけど、メンテナンス性が悪くなるじゃん。1日何百万PVもあるようなサイトなら、別の考え方もあるんだろうけどな。
0974nobodyさん2008/12/22(月) 12:01:34ID:???
１枚のテーブル？
あんまり関係ない希ガス

0975nobodyさん2008/12/22(月) 12:07:14ID:???
>>973
1枚のテーブルを分割したいんならＩＤ振ってINNER JOINすればいいじゃん。
0976nobodyさん2008/12/22(月) 12:13:33ID:???
大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。
0977nobodyさん2008/12/22(月) 16:22:33ID:???
大規模サイトでも、テーブルを非正規化するのはほどほどにしておいて、
なんでもかんでもコンテンツはキャッシュにぶちこんで、
検索が必要な場合は専用のインデックスにでも(RDBMSじゃなく、いやRDBMSでもいいけd)放りこめ!って
やりかたがイマドキはアレな気がする。

チューンしたSQLは一発書いたら使いまわしのできないコードだし、
コンテンツキャッシュがちゃんとしてれば大方はそっちの方が数字は速いし、
フレームワークなんかにも組み込みやすいし、なのでまぁそういう流れなんだと思う。
大規模サイトっつってもいろいろあるだろうけどさ。
0978nobodyさん2008/12/22(月) 16:30:59ID:???
> やりかたがイマドキはアレな気がする。

アレってなに
0979nobodyさん2008/12/22(月) 22:30:57ID:???
INNER JOIN談義に花が咲く…LEFT JOINを多用していたので参考になります。＾＾
0980nobodyさん2008/12/22(月) 22:54:57ID:???
そもそも、INNER JOIN と LEFT JOIN は意味が違う。
0981nobodyさん2008/12/22(月) 23:01:35ID:???
>>976
> 大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。
知識では知っていたが、最近実感した。

JOINにかかる速度というより、
一般的にSQLを実行したとき、条件やソート処理も一緒に行う。
条件やソートにインデックスがうまく使われれば速いが、
そうでない場合大幅に速度が遅くなる。

インデックスはRDMSによるが、一つのSQLで一回しか使われなかったりと
使われない場合がある。
JOINが絡むと結果的に複雑なSQLになり、インデックスをうまく使うのが難しい。
だからJOINを使った複雑なSQLを書くのではなくインデックスを使った
単純なSQLを複数回発行するほうが良い。
0982nobodyさん2008/12/22(月) 23:24:29ID:???
そりゃjoinしないで済むならしないけど仕方ないじゃん
1対多とか多対多を一つのテーブルでやるなんて無理ぽ
0983nobodyさん2008/12/22(月) 23:27:21ID:???
>>977

>検索が必要な場合は専用のインデックスにでも

そうそう。Luceneみたいにインデックスに特化させたシステムを別に走らせて
DBからはデータだけを取ってくる。ページはキャッシュしとく。
0984nobodyさん2008/12/23(火) 00:09:01ID:???
>>959
UserとProfileが一対一の関係で
しかも、
Userレコードに対応するProfileレコードが必ず存在する
という前提でないとINNER JOINは使えないと思う。

Userテーブルにたくさんデータがあって、Profileテーブルが空の場合、
$this->User->find('all');
としても、データが返ってこないことになる。

この場合CakePHPだとNULLになるのかな。
0985nobodyさん2008/12/23(火) 00:10:53ID:???
多対多は何も考えずにJOINで表現すると激重になるらしい
といって、インデックス？のシステムを利用してどう表現するのかよくわからない
うー頭が悪い

テーブル[A]： 1:太郎 2:花子 3:ジョニー
テーブル[B]： a:バナナ b:メロン c:マンゴー
テーブル[C]： 1-a, 1-b, 2-b, 2-c, 3-a, 3-c

こうすりゃJOINなんか使わなくていいんだぜ！ってのがあるのならだれか教えて下さい。
それとも、こんなのなら迷わずINNER JOINでいいのかな・・・
件数が少なけりゃ、例えばメロンが好きな人！ってので、テーブルCから名前キーを
取得して、テーブルAから IN (1, 2) とかでセレクトできるけど・・・そういうことするんでしょうか？

てか、PHPかDBの初心者スレいった方がいいかな；_；
レス数が950を超えています。1000を超えると書き込みができなくなります。