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


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

【PHP】Laravel【フレームワーク】 Part.7



685 名前:nobodyさん mailto:sage [2021/07/07(水) 21:52:48.55 ID:???.net]
あのさぁ、お前達の読解力なんとかしてくれ。


> 複合主キーでなくともJOINはできるだろw
> JOINの件は複合主キーとは関係ないよ

その通り、JOINには直接は関係ない。

1. 普通のテーブル設計すると、テーブルに従属関係が出来るので、複合プライマリキーは必ず必要になる
2. テーブルに従属関係を作るのは、主テーブルのレコードに紐づく従属テーブルのレコードを関連付けてSELECTしたいから
3. 当然、JOINしたくなる
4. テーブルに紐付いているORMだと、SELECT結果がORMの設計理念から外れるため、JOINを実装しづらい。

これを逆算すると、1を禁止するのが一番良いという結論にたどり着く。
自分でActiveRecordパターンのORM作ってみれば、はっきりと分かる。
『あ、そもそものORM設計間違ってた』って。でも、後戻りは出来ない。

PHPは元々メンバ変数を動的に作成できて
例えば結果を \stdClassオブジェクトに対してマッピングすれば、無理やりJOINを実装しても破綻しないけど、
それは結局、場当たり対応以外の何物でもなくなる。


> このorder_idとitem_idが複合ユニークにすればいいだけちゃうのか?

それ、妥協案っていうんだよ普通。そうすれば確かに問題は起きないだろうな。
でもな、

お前の上げたその解決法の事“こそ”を、世間一般では『テーブル設計が悪い』って言うんだよ、普通。
RDBの






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

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

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