int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。

勝手に値はいるのはtimestampだけだっけ？

>>602
NOT NULL にしておいて default を設定すれば入るだろ

mysqlはデフォルト値に関数が使えない

>>600
deletedってどういうこと？

フィールド名じゃないの？

ああそういうことか、関数かと思ったｗ

nullだとインデックスが使われないから論理値のほうが良くない？

nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない

というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。

>>608
MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ
他のDBでは知らない

>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。

あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。

いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。

論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！

と思うんだよなー
スレ趣旨と全然関係ないんだけどなー

>>612
頭文字使うぐらいなら、enum型かSET型じゃね？
まぁ、DB実装によって違うかもしれんけど。

論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ

>>615
そうだね。

論理削除っていう呼び方はおかしいね
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい

そうかな？英文でもphysical delete、logical deleteって言葉よく使われるよ。
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_developer.doc/doc/connector_dev_java/java61.htm

処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。

だからそれを削除って呼ぶなよﾊﾞｰﾔ!!って言いたいんだろう

論理削除を削除と呼ぶか、単なるステータスかというのは
呼び方の慣習の問題。

言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？

>>600 >>612
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。

削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？

partial index 使っちゃう。

>>622
詳しく

>>624
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。

書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ

＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。

こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。

って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。
飲みながらレスするもんじゃないな。
退散します。

>>625
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。

酔っ払いめ！ｗｗ

さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。

>>629
そういうのの設計はちょっと知りたいなーと思っていたんだけど、
MediaWikiのソースでも読めばいいのかな？

PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは?
リビジョンと直接は関係ないけどソースはしっかりしてるかも

設計見るのになぜソースを読む

オープンソースソフトウェアの設計書なんて公開されてる？

おそれすになったな・・・

>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。

画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ

>>633
設計書 = ソースコード

>>634
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。

>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。

いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？

タグの実装を考えています
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください

>スペース区切りでtextカラムに入れて、全文検索
これはひどい

そうですか？ググっていたら同じようなことしてる人もいますが。
http://blog.nomadscafe.jp/archives/000643.html
他にいい方法があれば教えてください。

タグ単位で編集とかしないならいいんじゃない？

普通に考えれば
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど

>>639
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね

だね
基礎知識が足りてなさそう

なるほど、おっしゃる通りですね。
ありがとうございました。

俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。

だから典型的なリレーショナルな設計でいいでしょ
それ以外に特別な事なんて無いんだから

うん基本的すぎてまとめる気が起きない
不安ってのはRDBの理解が不十分なのかと。

フレームワークの話題が無いのか

symfony使ってるんだけどRoRと比べてモデル周りが貧弱で泣いた

PHPの場合、標準的なDBドライバがないからな。どれも中途半端。