1 名前:nobodyさん mailto:sage [2008/08/24(日) 21:43:37 ID:???] 前スレ pc11.2ch.net/test/read.cgi/php/1202521438/
545 名前:nobodyさん mailto:sage [2008/11/10(月) 23:39:13 ID:???] MobaSiF読んでPHP用携帯FWを作るプロジェクトとか
546 名前:nobodyさん mailto:sage [2008/11/11(火) 00:37:30 ID:???] そもそも初期のiモードなんかの仕様がダメ杉
547 名前:nobodyさん mailto:sage [2008/11/11(火) 02:17:34 ID:???] >>545 PerlのコードをPHPのコードに変換するジェネレーターがあれば、簡単に移植できるかな?
548 名前:nobodyさん mailto:sage [2008/11/11(火) 02:22:07 ID:???] oshiete1.goo.ne.jp/qa863429.html Perlコードを、自動的にPHPコードに変換してくれる、そんな「ドラえもん」のようなプログラムがありましたら教えて下さい! 無いですねえ。 www.cs.wcupa.edu/~rkline/perl2php/ Perl/Php Translation
549 名前:nobodyさん mailto:sage [2008/11/11(火) 07:51:48 ID:???] そういやperlで思い出したけど PHP on parrotて進んでるんでしょうか?
550 名前:nobodyさん mailto:sage [2008/11/13(木) 08:51:01 ID:???] >>540 Perlの事情あまりしらはい。ライブラリのどういうとこが携帯向き?
551 名前:nobodyさん [2008/11/13(木) 10:31:16 ID:kdvrTOAA] で、肝心のフレームワークなんだけど 結局今熱いのってなんなの? いっぱいありすぎていまいちこれっていう特徴あるやつ ないんだよな〜 最近ちょっとさわってみようかな〜って思ってるのあるんだけど 誰かいじったことある人いたら所感教えて〜 PAJAJ ttp://pajaj.sourceforge.net/ xFrameworkPX ttp://px.xframework.net/
552 名前:nobodyさん mailto:sage [2008/11/13(木) 14:00:08 ID:???] PRADOみたいなイベントドリブンなのはどうなんだ
553 名前:nobodyさん mailto:sage [2008/11/13(木) 16:16:39 ID:???] ちいたんでいい
554 名前:nobodyさん mailto:sage [2008/11/13(木) 23:25:55 ID:???] やっぱり落ち担当w
555 名前:nobodyさん mailto:sage [2008/11/13(木) 23:27:41 ID:???] もうちょっとふくらませてからw
556 名前:nobodyさん mailto:sage [2008/11/13(木) 23:41:23 ID:???] いやらしい
557 名前:nobodyさん mailto:sage [2008/11/14(金) 13:45:00 ID:???] 大規模向けのFWはどれ?
558 名前:nobodyさん mailto:sage [2008/11/14(金) 13:52:53 ID:???] ちいたん
559 名前:nobodyさん mailto:sage [2008/11/14(金) 13:53:13 ID:???] 出ると思ったw
560 名前:nobodyさん mailto:sage [2008/11/14(金) 14:12:00 ID:???] ちいたん以外で
561 名前:nobodyさん mailto:sage [2008/11/14(金) 14:31:47 ID:???] Symfony Cake
562 名前:nobodyさん mailto:sage [2008/11/14(金) 14:34:00 ID:???] あれ?遅いとか叩いてなかったっけか? なぜ大規模向けと?
563 名前:nobodyさん mailto:sage [2008/11/14(金) 14:42:11 ID:???] 軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい (重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい とはいえ、フレームワークが案件に合う合わないもあるので、 どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。 逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。 重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。 あと、大規模=多人数と勝手に解釈したけど。
564 名前:nobodyさん mailto:sage [2008/11/14(金) 14:50:52 ID:???] 数年がかりの本当に大規模なものなら 逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある
565 名前:nobodyさん mailto:sage [2008/11/14(金) 15:31:36 ID:???] >>564 開発期間が数年?PHPでそんな案件はほとんど無いけど。 あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように 古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。 やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな?
566 名前:nobodyさん mailto:sage [2008/11/14(金) 16:00:34 ID:???] 1年未満じゃ大規模とは言えないし
567 名前:nobodyさん mailto:sage [2008/11/14(金) 16:19:50 ID:???] webアプリで開発に何年もかかってちゃビジネスになんね。
568 名前:nobodyさん mailto:sage [2008/11/14(金) 16:22:17 ID:???] PHPはインタフェース部分を担当するに過ぎないから プロジェクト全体で数年っていうのはあるよ 複数サイトを作るような事業でも共通フレームワークを作成することはあるし
569 名前:nobodyさん mailto:sage [2008/11/14(金) 16:31:35 ID:???] 単純にスピードを比較したものがよく出るけど、あまり意味無いよな。 しかも素の状態に近いベンチとか。 もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。 色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。 だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。 単純なスピード比較がよく話題が出るから、疑問に感じていた。
570 名前:nobodyさん mailto:sage [2008/11/14(金) 16:52:52 ID:???] 何が言いたいのかさっぱりだ 帰れ
571 名前:nobodyさん mailto:sage [2008/11/14(金) 22:44:45 ID:???] 必要な機能に一番近いものを使えばいいねん 多すぎず少なすぎず
572 名前:nobodyさん mailto:sage [2008/11/14(金) 23:35:14 ID:???] それがベストだけどちょうどいいFWってそうはない気も。 まぁ、一番近いものを選べばいいが
573 名前:nobodyさん mailto:sage [2008/11/14(金) 23:36:59 ID:???] フレームワークなんて多機能な奴はほとんど一緒だけどね パフォーマンスくらいしか差が無い気が
574 名前:nobodyさん mailto:sage [2008/11/14(金) 23:49:38 ID:???] 大規模の意味は100万ユーザ以上が使うというアクセス数の意味で 開発の工数ではなかったけどためになった アクセス数という意味では軽量かどうかが非常に重要と思われ サーバの台数などのメンテナンス代が高くつくから とはいえ重量級のものを使ってあとからプロファイリングして リファクタリングなりすればいいような気もしてきた
575 名前:nobodyさん mailto:sage [2008/11/14(金) 23:58:04 ID:???] 必要な機能なら実装しなきゃならないんだから 効率的な実装になってるならいいんだけどね cakeは実装が酷いよ
576 名前:nobodyさん mailto:sage [2008/11/14(金) 23:59:29 ID:???] cakeはインターフェイスが全てだからじゃん その辺までRailsを踏襲していると言えばそうかも
577 名前:nobodyさん mailto:sage [2008/11/15(土) 02:26:07 ID:???] ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。 でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。 PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。 GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。
578 名前:nobodyさん mailto:sage [2008/11/15(土) 02:37:10 ID:???] アクセス数の多さはフレームワークのスレで大規模にあたらないだろ 1ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか? 俺は普通コード量とか機能数だと思うけど
579 名前:nobodyさん mailto:sage [2008/11/15(土) 02:38:10 ID:???] Googleは独自のフレームワーク作ってそうだけどね てか絶対作ってる 他にも大企業は手の込んだ事やってそうだけどなあ
580 名前:nobodyさん mailto:sage [2008/11/15(土) 02:50:13 ID:???] ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。 mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。 ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。 これをひたすら繰り返して巨大化するだけ。
581 名前:nobodyさん mailto:sage [2008/11/15(土) 02:53:39 ID:???] 機能によっては違うこともあるんじゃないか。 ユーザからのデータを何かしら加工するとか、 なにか特別なアルゴリズムでデータを収集して、 それを提供するとか。
582 名前:nobodyさん mailto:sage [2008/11/15(土) 03:02:01 ID:???] WEBAPIの提供に際する共通機能とか 自動的にDBを保守してくれたりHDD壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか (PHPコード内の接続先DBサーバIPが動的に変わるって事ね) 思いつきで書いた
583 名前:nobodyさん mailto:sage [2008/11/15(土) 04:39:48 ID:???] ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。
584 名前:nobodyさん mailto:sage [2008/11/15(土) 05:03:15 ID:???] >>580 > ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。 > mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。 > ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。 > これをひたすら繰り返して巨大化するだけ。 それはウェブアプリだからではなく、SNSやオンラインショップという システムが、そうなっているってだけだろ。 たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。
585 名前:nobodyさん mailto:sage [2008/11/15(土) 05:05:22 ID:???] それにウェブじゃないシステムが何をしているかというと、 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
586 名前:nobodyさん mailto:sage [2008/11/15(土) 05:47:54 ID:???] 大したことやってないのにフレームワークは重いから使わない(キリッ なんて言っちゃってる企業とか腐るほどあるからなぁ
587 名前:nobodyさん mailto:sage [2008/11/15(土) 09:41:57 ID:???] >>585 インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。 ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。 >>586 その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね?
588 名前:nobodyさん mailto:sage [2008/11/15(土) 13:00:48 ID:???] フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。 つーかFWに組み込まれてるし
589 名前:nobodyさん mailto:sage [2008/11/15(土) 13:15:36 ID:???] 何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい やり方を検討するのが面倒くさいことだけの事が多いと思う。 論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。 あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている 会社があった。 なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。 全力でこけた。いろいろ間違ってる。
590 名前:nobodyさん mailto:sage [2008/11/15(土) 14:11:03 ID:???] 12のphp最適化テクニックとか、一時期ブログに出回ったけど、 そのテクニックが使われるタイミングを考えると、誤差でしかないとか、 よくあったよね。 むしろコードが読みにくくなったり、書きにくくなったりと、 その時間のほうがもったいないとか。
591 名前:nobodyさん mailto:sage [2008/11/15(土) 14:39:00 ID:???] 大手でphp使ってサービスやってるといえばYahooなんだけど たとえば、↓ www.sooey.com/journal/2007/05/26/648/ symponyだって。 でもサービスによって違いはあって wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128 ↑これなんてPHP?
592 名前:nobodyさん mailto:sage [2008/11/15(土) 14:39:25 ID:???] 論理削除自体間抜け
593 名前:nobodyさん mailto:sage [2008/11/15(土) 14:54:51 ID:???] 論理削除自体が間抜け? 方法がフラグってとこが間抜けってなら少しはわかる気もするが。
594 名前:nobodyさん mailto:sage [2008/11/15(土) 14:55:03 ID:???] 論理削除は必要だろ。
595 名前:nobodyさん mailto:sage [2008/11/15(土) 15:09:50 ID:???] スレチだけど論理削除ってどういう指定にすればやりやすいですかね。 active enum('Y','N')か、status = 0 なら削除とか?
596 名前:nobodyさん mailto:sage [2008/11/15(土) 15:11:46 ID:???] >>593 わかんね。 フラグじゃなくてカウンタにするってこと?
597 名前:nobodyさん mailto:sage [2008/11/15(土) 16:06:02 ID:???] 大規模向けではなく一番スケールアウトしやすいFWは?
598 名前:nobodyさん mailto:sage [2008/11/15(土) 16:34:55 ID:???] スケールアウト考えたらモデルは自分で書かないときつくね?
599 名前:nobodyさん mailto:sage [2008/11/15(土) 16:57:52 ID:???] ちry
600 名前:nobodyさん mailto:sage [2008/11/15(土) 17:24:52 ID:???] >>595 deleted(datetime)がnullかどうか
601 名前:nobodyさん mailto:sage [2008/11/15(土) 17:52:20 ID:???] int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
602 名前:nobodyさん mailto:sage [2008/11/15(土) 17:55:22 ID:???] 勝手に値はいるのはtimestampだけだっけ?
603 名前:nobodyさん mailto:sage [2008/11/15(土) 18:02:15 ID:???] >>602 NOT NULL にしておいて default を設定すれば入るだろ
604 名前:nobodyさん mailto:sage [2008/11/15(土) 18:49:10 ID:???] mysqlはデフォルト値に関数が使えない
605 名前:nobodyさん mailto:sage [2008/11/15(土) 18:51:03 ID:???] >>600 deletedってどういうこと?
606 名前:nobodyさん mailto:sage [2008/11/15(土) 19:09:25 ID:???] フィールド名じゃないの?
607 名前:nobodyさん mailto:sage [2008/11/15(土) 19:12:51 ID:???] ああそういうことか、関数かと思ったw
608 名前:nobodyさん mailto:sage [2008/11/15(土) 19:13:24 ID:???] nullだとインデックスが使われないから論理値のほうが良くない?
609 名前:nobodyさん mailto:sage [2008/11/15(土) 19:27:12 ID:???] nullかどうかで求めるのは本来正しく無いだろうね 削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
610 名前:nobodyさん mailto:sage [2008/11/15(土) 19:54:48 ID:???] というか、3値論理っての? NULL を理解していないとか必要性を感じないとかの場合は、 全フィールド NOT NULL で作ってしまえと言いたい。 その方が何かとトラブルが少ないし、コーディングも楽だ。 テキストフィールド? 空文字でも入れとけ。 数値? 0が初期値だ。それで都合がわるけりゃ、 -999999999 が初期値だ、文句あるか、ってな感じで。
611 名前:nobodyさん mailto:sage [2008/11/15(土) 22:00:11 ID:???] >>608 MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ 他のDBでは知らない
612 名前:nobodyさん mailto:sage [2008/11/15(土) 23:07:45 ID:???] >>607 そう、カラム名。 id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。 あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted とか詳しい状態が必要な時に使うとか。
613 名前:595 mailto:sage [2008/11/15(土) 23:12:27 ID:???] いろいろやり方あるんすね。すごい勉強になった。 皆さん有り難うございます。
614 名前:nobodyさん mailto:sage [2008/11/15(土) 23:21:42 ID:???] 論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね 実際問題何も消してないわけなんだし だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで 削除って言うならならきっちりかっちりまるっと全部消してしまえ! と思うんだよなー スレ趣旨と全然関係ないんだけどなー
615 名前:nobodyさん mailto:sage [2008/11/15(土) 23:47:46 ID:???] >>612 頭文字使うぐらいなら、enum型かSET型じゃね? まぁ、DB実装によって違うかもしれんけど。
616 名前:nobodyさん mailto:sage [2008/11/16(日) 02:05:02 ID:???] 論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか 警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614 みたいに消してしまえーが使えない場合も少なくないよ >>615 そうだね。
617 名前:nobodyさん mailto:sage [2008/11/16(日) 02:08:47 ID:???] 論理削除っていう呼び方はおかしいね ソフトウェアなんだから全て論理だし 無効化、凍結、と言う呼び方が正しい
618 名前:nobodyさん mailto:sage [2008/11/16(日) 02:19:28 ID:???] そうかな?英文でもphysical delete、logical deleteって言葉よく使われるよ。 publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_developer.doc/doc/connector_dev_java/java61.htm
619 名前:nobodyさん mailto:sage [2008/11/16(日) 03:13:45 ID:???] 処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。
620 名前:nobodyさん mailto:sage [2008/11/16(日) 06:39:55 ID:???] だからそれを削除って呼ぶなよバーヤ!!って言いたいんだろう
621 名前:nobodyさん mailto:sage [2008/11/16(日) 06:56:48 ID:???] 論理削除を削除と呼ぶか、単なるステータスかというのは 呼び方の慣習の問題。 言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、 物理的には削除せずにサービス上削除されたようにふるまわせること でいいかな?
622 名前:nobodyさん mailto:sage [2008/11/16(日) 09:11:01 ID:???] >>600 >>612 滔々と語ってるが、>>612 の前者のdeleted (削除日時) はまあともかく、 後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。 削除フラグ(というかカウンタなど)とセットでユニーク制約にしてしまうって のは、あんまり流行って無いのか?
623 名前:nobodyさん mailto:sage [2008/11/16(日) 12:27:21 ID:???] partial index 使っちゃう。
624 名前:nobodyさん mailto:sage [2008/11/16(日) 12:33:30 ID:???] >>622 詳しく
625 名前:nobodyさん mailto:sage [2008/11/16(日) 13:00:36 ID:???] >>624 例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。 んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。 それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと2カラム連結で ユニークにしてしまう。 んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。 削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。 こんなやり方。マイナーなのかな?と思った。 書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなw もちょっと応用を利かさないと無理か。 整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかwww # DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
626 名前:nobodyさん mailto:sage [2008/11/16(日) 13:06:04 ID:???] こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
627 名前:nobodyさん mailto:sage [2008/11/16(日) 13:24:25 ID:???] って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。 飲みながらレスするもんじゃないな。 退散します。
628 名前:nobodyさん mailto:sage [2008/11/16(日) 13:45:33 ID:???] >>625 その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
629 名前:nobodyさん mailto:sage [2008/11/16(日) 13:51:02 ID:???] 酔っ払いめ!ww さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、 CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで 複数のインスタンス、しかも最新以外は非アクティブっていう状態を 表現するという用途があったりする。 その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。 外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
630 名前:nobodyさん mailto:sage [2008/11/16(日) 14:12:40 ID:???] >>629 そういうのの設計はちょっと知りたいなーと思っていたんだけど、 MediaWikiのソースでも読めばいいのかな?
631 名前:nobodyさん mailto:sage [2008/11/16(日) 14:19:46 ID:???] PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは? リビジョンと直接は関係ないけどソースはしっかりしてるかも
632 名前:nobodyさん mailto:sage [2008/11/16(日) 14:26:24 ID:???] 設計見るのになぜソースを読む
633 名前:nobodyさん mailto:sage [2008/11/16(日) 14:43:16 ID:???] オープンソースソフトウェアの設計書なんて公開されてる?
634 名前:nobodyさん mailto:sage [2008/11/16(日) 15:05:16 ID:???] おそれすになったな・・・ >>587 > インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。 > ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。 それをいったら、ウェブじゃないアプリだって、ほぼ画面(ディスプレイ)相手だろ? なんか比較している対象がずれてるよ。 画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。 ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。 ブラウザでコーヒー沸かす装置とかw
635 名前:nobodyさん mailto:sage [2008/11/16(日) 15:05:49 ID:???] >>633 設計書 = ソースコード
636 名前:nobodyさん mailto:sage [2008/11/16(日) 15:33:36 ID:???] >>634 元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね? 対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは わかっててわざと書いてるんだろw 車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの?って。 >>585 > それにウェブじゃないシステムが何をしているかというと、 > 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。 いえねーよw これがむしろ、言いたいことと表現がずれてるんじゃね?
637 名前:nobodyさん [2008/11/16(日) 17:24:18 ID:+7h73lOI] タグの実装を考えています スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、 他にいい方法があったら教えてください
638 名前:nobodyさん mailto:sage [2008/11/16(日) 17:26:45 ID:???] >スペース区切りでtextカラムに入れて、全文検索 これはひどい
639 名前:nobodyさん [2008/11/16(日) 17:28:47 ID:+7h73lOI] そうですか?ググっていたら同じようなことしてる人もいますが。 blog.nomadscafe.jp/archives/000643.html 他にいい方法があれば教えてください。
640 名前:nobodyさん mailto:sage [2008/11/16(日) 17:43:46 ID:???] タグ単位で編集とかしないならいいんじゃない?
641 名前:nobodyさん mailto:sage [2008/11/16(日) 17:44:48 ID:???] 普通に考えれば タグテーブル作って アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね いかにもリレーショナルに解決出来るケースだと思うけど
642 名前:nobodyさん mailto:sage [2008/11/16(日) 17:45:10 ID:???] >>639 それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。 DBの問題だからDB関連スレで質問しろよ。 まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
643 名前:nobodyさん mailto:sage [2008/11/16(日) 17:52:11 ID:???] だね 基礎知識が足りてなさそう
644 名前:nobodyさん mailto:sage [2008/11/16(日) 17:59:55 ID:???] なるほど、おっしゃる通りですね。 ありがとうございました。
645 名前:nobodyさん mailto:sage [2008/11/16(日) 18:01:45 ID:???] 俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。 けど、割とありきたりの機能になったのに、 情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。 タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。