元スレ【PHP】Laravel【フレームワーク】 Part.5

php覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

151 = :

多様性を認めない昭和な人が多いインターネットですね

152 = :

>>149-151が荒らしの自演
これを延々繰り返してきた、またやるつもりか

153 = :

>>152
勝手に仕切るなよ

154 = :

ワッチョイ隔離スレに帰れよ

155 = :

また.envをコミットするなとか言う老害現れたよ
そんなの現場次第だろ

156 = :

うちは上司の指示でどうしてもコミットさせられるわ

157 = :

>>154
荒らしがわざわざワッチョイ付きでレスすると思うか？
.envコミットするとか言ってる奴らはどうせほとんど自演だろうな

158 = :

嘘つけ
向こうが過疎ったからこっちに来たんだろ

159 = :

と思ったけど向こうのスレはかっそかそで荒らしすら居なかったわw

160 = :

.envをコミットしたほうが良いと自身で思い込んでる奴が居るってのはまだ分かる。
個人的に一番謎なのは、客や上司の指示で.envをコミットしてるけど、自身は.envをコミットしたく無いって奴ね。
前スレにもちょくちょく居たけどさ、頼まれたらなんでもするのか？

161 = :

複合主キーはあきらめてサロゲートするしかないのではないかね？

162 = :

>>160
客が.envをコミットしろって言うケースがそもそも分からん
そんなこと客は関心無いと思うんだが

163 = :

>>162
どちらかというと関心ないからこそ.envをコミットしてくれって依頼があるのでは？
そうでもないと.envコミットに関心がないことになってしまうわけで

164 = :

サロゲートの方が取り回しが楽

165 = :

言われて思い出したけど、そうそう、
PHPのフレームワーク、ライブラリで“複合プライマリキー”に対応してるの、見たことない。
確かRailsのActive Recordもそうだよな？　確か。
『これ設計した奴、何考えて作ってたんだろう？』といつも思ってた。

>>141
> できないよ。複合主キーサポートすべきだｔってissues作られたけど却下された
>http://github.com/laravel/framework/issues/5355

どうして却下しちゃうかなぁ…。

166 = :

>>146
.envの件はどの環境でも同じ値使ってるから.envコミットしたほうが良いとか言ってたので、それならconfigのデフォルト値に書くべきって言われて反論できなくて終わったはず。

167 = :

これこそ宗教

168 = :

.envをコミットするメリットデメリットを説明して上司を納得させられないんだろ多分。日々の業務でいっぱいいっぱい

169 = :

その辺はデフォルトのままの運用が一般的では？

170 = :

>>156の上司もなんか意図があってコミットさせてるんでしょ　知らんけど

171 = :

意図が全く無い行動をする人間の方が、今の日本では圧倒的多数派なんだよね…。

172 = :

>>171
なにしろ「前例に従う」のが大好きだからね
違うことをして失敗したら、吊し上げられるし

173 = :

(なんで前例に意味がないって思ってんだろ。。。)

174 = :

（相手が意味を説明出来ないからに決まんじゃん。。。）

175 = :

>>173
前例ってのは成功例に限るからな

178 = :

Laravelのissuesによるとそもそも複合主キーができちゃうようなテーブル設計をするほうが悪いから
サポートしないとのこと

179 = :

> そもそも複合主キーができちゃうようなテーブル設計をするほうが悪いから

なんすか、これ？

そんなわけないじゃないっすか。
まともなDB設計、した事ないんすか？　Laravel開発者は？
馬鹿しか居ないんすか？

180 = :

だーめだ、Laravel。確信したわ。

181 = :

使う人間がフレームワークを選ぶというよりは、フレームワークが使う人間を選ぶんだよな

182 = :

俺個人は複合主キー使わないけど>>178はおかしいと思う
なんでそんなの言い切れるんだ？

183 = :

他のフレームワークも複合キーは使うな方針らしい

185 = :

>>179
Laravelどころか基本的にORM開発者はみんな複合主キーはテーブル設計が悪いって結論に至ってるからサポートしないのが多いんだよね

186 = :

そういえばCakeもそうだったような
初めて使ったFWがCakeだったんだが、そういう不便さを我慢しても高速に開発するために使うのがFWってもんだと思ってた
「複合主キーはテーブル設計が悪い」という意味不明の信念があったとは知らなかった、DBちゃんと勉強した人間ならおかしいと思うよな

187 = :

ORM開発者は複合主キーではなくユニークキー使えよって感じだよね

188 = :

主キーは主キーでUUIDでも使えば良いんじゃないの？
知らんけど

189 = :

複合ユニークは使えるんだしそんなに問題になった事はないなぁ
サロゲートキー自体が好きでないという層はいるよね

190 = :

>>185
> Laravelどころか基本的にORM開発者はみんな複合主キーはテーブル設計が悪いって結論に至ってるからサポートしないのが多いんだよね

そんなの、嘘うそ。

ORM開発で必ず問題に成ってくるのが『JOINをどうするか』問題。
DAOもActiveRecordも、基本は１テーブル対１Class、つまり、ORMが『テーブルに対して』紐付いている。
その設計では基本的に『JOINが実質出来ない』。エンティティもテーブルに対して紐づく為に、が対応できなくなるから。

だから、DAOやActiveRecordのアプローチでORM開発してる奴らは『JOINさせたくない』ので、複合プライマリキーを認めたくない。

例えば商品の注文場合、最低限で考えても必ず
注文伝票のプライマリキー：order_id
注文商品のプライマリキー：order_id, item_id
となる。

これをしないデータベース設計なんか見たこと無い。
これを『テーブル設計が悪い』って言う奴が居るとしたら、そりゃもう、『おまえ、脳みそ腐ってるだろ？』としか言えない。

191 = :

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

192 = :

>>190
長ったらしく書いてるけど注文のテーブルだったら
ordersにid,注文関連の情報など
order_detailsにid,order_id,item_id,countなど
このorder_idとitem_idが複合ユニークにすればいいだけちゃうのか？

193 = :

>>191,192
あのさぁ、お前達の読解力なんとかしてくれ。

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

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

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

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

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

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

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

お前の上げたその解決法の事“こそ”を、世間一般では『テーブル設計が悪い』って言うんだよ、普通。
RDBの思想に、明らかに反してるだろ。本末転倒なんだよ、お前の言ってる事。