12/02/26 18:40:50.31
話題が基礎的すぎて興味ないんだろ
883:NAME IS NULL
12/02/26 18:42:44.36
もう放置でいいんじゃね？
884:NAME IS NULL
12/02/26 20:48:19.43
>>881
交差エンティティはエンティティ間の関連を表現するもので、ERモデルで
設計する場合に用いられるもの。>>864でいえばABあるいはabにあたる
エンティティが存在してそのとき>>864を交差エンティティと呼ぶが、
>>864はそうではない。
なんかそのへん混同している人が多いみたいだが、RDBとERは
イコールじゃないぞ。RDBの入門書なんかでいきなりエンティティが
出てくるものもあったりするから仕方ない面もあるが。
885:NAME IS NULL
12/02/26 21:02:07.84
お前らの言ってることが全然分からない
おすすめの書籍を教えて
886:NAME IS NULL
12/02/26 21:30:16.89
>>880
そういえば最近見たニュースで、「偶数と奇数を足すと必ず奇数になることを
説明せよ」という問題に「思いつく偶数と奇数を足したら全て奇数だった」という
回答を書いた大学生がいたというのがあったな。
887:NAME IS NULL
12/03/04 08:00:00.89 p3r4LXDn
掲示板をつくっています。
・親投稿
└ 子投稿
└ 子投稿
のように１つだけコメントができるようにしたいのですが、
投稿テーブル、コメントテーブルと分けたほうがいいですか？
同じ情報を保持しているので、なるべく１つのテーブルで簡潔させて、
なおかつJOINで１度に子投稿も一緒に取得したいのですが、
・実装方法・その実装での子投稿を含んだ投稿を取得するSQL
を助言してもらえませんか？
関連付けのためのテーブルができてもかまいません。
888:NAME IS NULL
12/03/04 11:05:32.76
>>887
あほか
889:NAME IS NULL
12/03/04 14:17:36.42
>>887
投稿テーブルとコメントテーブルで想定するフィールド名を示した上で、
SQL質疑応答スレ 12問目
ｽﾚﾘﾝｸ(db板)
に行くといいよ。
890:NAME IS NULL
12/03/04 15:50:04.00 ku1dl9VL
今動いているシステムのER図を作りたいのですが
ダンプしたsql文放り込んだらER図を作ってくれるようなソフトありませんでしょうか？
891:NAME IS NULL
12/03/04 15:51:27.03
dbmsは？
892:NAME IS NULL
12/03/04 16:09:29.30 ku1dl9VL
MySQLですが、関係あります？
893:NAME IS NULL
12/03/04 16:10:34.83
Workbenchで桶
894:NAME IS NULL
12/03/04 19:02:46.05
>>887
親投稿(投稿テーブル)と子投稿(コメントテーブル)が「同じ情報を保持している」のだから、
単一テーブルで設計してもかまわないと思う
（本当に「同じ情報」であるという条件付き。後出しで「実は....」なんてのは勘弁してネw）
具体的なテーブル設計としては、たとえば以下のフィールドを持つ
単一の「投稿テーブル」を定義する
・投稿IDフィールド -- PK, シリアル型
・区分フィールド -- 文字列型, 値制約: "親" または "子"
・親IDフィールド -- FK, 整数型, 参照性制約: 投稿テーブル.投稿IDフィールド
・(その他の共通情報を表現する複数のフィールド)
親IDフィールドは、区分フィールド値が "子"の場合にのみ有効であり、
それ以外("親"の場合)はNULL(無効)とする
検索のSQL文については、まずは自分で考えよう(単一テーブルだから初歩レベルの問題)
もし考えても分からなかったら、このカキコを添えて>>889紹介のスレへ逝け
895:NAME IS NULL
12/03/05 16:17:32.82
>>894
区分フィールドいらなくね？
親IDがNULLなら親ってことだし
NULLがいやなら0でもいいけど
896:NAME IS NULL
12/03/05 17:20:17.94
>>894
子コメントの下にもコメントツリーをぶら下げられるようにしよう！
と、まるで専ブラやメーラーのように。
なんて言い出したとき、そのテーブルで「全然平気、任せとけ」と言えるか？
無駄を増やした挙げ句、能力を低下させてるかのようだ。
897:NAME IS NULL
12/03/05 18:05:27.12
>>896
そのときこそ単一テーブル化じゃないの？
コメントにコメントをぶら下げられるようにしよう！ってなったらさらにテーブル増やすの？
898:NAME IS NULL
12/03/05 21:47:58.70
>>897
区分フィールドもそのままで行くの？
899:894
12/03/05 22:21:56.70
>>895
たしかにこのお題(>>887)に限定すれば、
区分フィールド無しでも実装できるし設計も簡潔になるね
ただし、この区分フィールドは、親投稿と子投稿という
(投稿という全体集合に対する)部分集合に付けられた名前(ラベル)であり、
かつE-Rモデルにおける「エンティティ」を対象とする特性
それに対して、親IDフィールドは(E-Rモデルにおける)「リレーション」を表現する属性
つまり、E-Rモデル上で明確に区別される両者を
それぞれ区分フィールド(エンティティ)と親IDフィールド(リレーション)という形で
素直にDB設計へ反映させたのが、>>894の「キレイな設計」になる
これを理解した上で、(お題に限定して)設計を崩すことはかまわないと思う
>>896
すでに>>897が指摘しているけど、再帰的な親子関係(1:m関係)を実現するために
親IDフィールドを伴う単一テーブル方式を採用することは、よく知られた(=定石の)手法
900:NAME IS NULL
12/03/05 23:01:35.51
>>898
ある階層のデータを取得するのに、親子IDのみでは難しい(あるいはめんどくさい)場合に、階層を持たせることはあるね。
901:NAME IS NULL
12/03/06 00:34:11.18
>>899
子から先の孫以下ツリー生成に制限を持たせないように拡張する場合、
区分フィールドの仕様はどうなるの？
902:NAME IS NULL
12/03/06 03:16:34.21
素直にDBに反映させたってんならエンティティじゃない項目をエンティティのテーブルに入れるなよ
ちゃんとリレーション用のテーブル作るべきじゃねえの