[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 12/06 21:08 / Filesize : 167 KB / Number-of Response : 790
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:nobodyさん mailto:sage [2008/08/24(日) 21:43:37 ID:???]
前スレ
pc11.2ch.net/test/read.cgi/php/1202521438/

532 名前:nobodyさん mailto:sage [2008/11/10(月) 19:04:27 ID:???]
>>530
リファラーを送っちまう機種でそんなことしたら、セッションハイジャックされるべ

533 名前:nobodyさん mailto:sage [2008/11/10(月) 19:05:00 ID:???]
実際携帯サイト向けのソリューションはいくつかあるんだけど
国内では情報少ないね

534 名前:nobodyさん mailto:sage [2008/11/10(月) 19:10:08 ID:???]
>>530
POSTフォームだとACTIONに指定したパラメータを送らないっていう機種もあるしな
そういう機種ではPOSTフォームでセッションを維持できない。

535 名前:nobodyさん mailto:sage [2008/11/10(月) 19:23:29 ID:???]
結局機種判別をして処理振り分けるような事をする必要があるんだよね

536 名前:nobodyさん mailto:sage [2008/11/10(月) 19:35:22 ID:???]
ttp://gihyo.jp/dev/feature/01/mobasif/0001

ここに書いてあるのでもまだまだ序の口だな。間違ってるとこもあるし。
いまんとこ、オープンソースだとMobaSiF最強じゃないかな。

537 名前:nobodyさん mailto:sage [2008/11/10(月) 19:47:32 ID:???]
携帯の文字コードは、そろそろUTF-8統一でいいんでしょうか?

538 名前:nobodyさん mailto:sage [2008/11/10(月) 19:48:52 ID:???]
結局そういうのは自分とこで作るしかないんじゃね

539 名前:nobodyさん mailto:sage [2008/11/10(月) 19:54:03 ID:???]
>>536
Perlじゃん

>>538
別に汎用的な機能だから広く使われるものが無い現状が異常
携帯関連開発の低レベル差だと思う

540 名前:nobodyさん mailto:sage [2008/11/10(月) 20:24:13 ID:???]
うん。perlなんだけどさ。
スレチ承知であえて、携帯だけはPerlでって思えるぐらいの完成度だと思う。



541 名前:nobodyさん mailto:sage [2008/11/10(月) 21:08:55 ID:???]
だいたい携帯は規格が無さ杉なんだよ
OSも別々のが乗ってるし
エンドユーザーにとってメリットがある事じゃないんだが、不経済だなあ

542 名前:nobodyさん mailto:sage [2008/11/10(月) 22:50:10 ID:???]
>>541
それと、各社・各世代仕様のまとめ情報が少なすぎる。
ググれば出てきそうなクッキー仕様や対応文字コード等の情報が、ほとんど無い。
会社で仕事なんかでは資料を作るんだから、暇な自営業者あたりが自分メモで
作ってても良さそうなもんなんだが。

フレームワーク辺りと違って、いじって面白くないのと、商売上公開したくないって
のと、その他もろもろ理由はあるんだろうけど。

543 名前:nobodyさん mailto:sage [2008/11/10(月) 22:58:35 ID:???]
Androidに期待

544 名前:nobodyさん mailto:sage [2008/11/10(月) 23:09:02 ID:???]
携帯はフルブラウザで見る以外は廃止にすべき

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:???]
設計見るのになぜソースを読む






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<167KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef