>>646
アンチオートインクリメントおじさんの妄想だから、そこあんまり突っ込んでも得るものは無いよ。

>>649
やめたれｗそんなこと言うとまたbigintの枯渇時間がどうのこうのって反論してくるぞｗ

バカ過ぎるから再掲しとけ。

Laravelerの特徴

・.envをコミットする
・node_modulesをコミットする
・vendorをコミットする
・package-lock.jsonをコミットしない
・composer.lockをコミットしない
・認証にユーザIDを利用したいのでemailカラムにユーザIDを入れる
・認証にユーザIDを利用したいのでvendor直下のファイルを修正する
・トランザクションや排他を知らない←NEW

http://medaka.5ch.net/test/read.cgi/php/1624434493/548

Laravelerは、
1. 平行実行可能なシステムでは、まず真っ先に採番する
2. 勿論、オートインクリメント採番！　だからユーザーがキャンセルすると歯抜けになるのは仕方ない
3. 園団の一匹の口伝により、突然全児童でSELECT FOR UPDATEを連呼し始める。
4. SELECT FOR UPDATEなんか使ったらデッドロックが起きるぞ！　と、謎の警鐘を鳴らす児童出現
5. RDBMSの設定やバージョンにまで言及し始める　←　イマココ！

顧客が本当に必要だった物
・新規ユーザー登録時に欠番しない連番が発行されるシステム

http://medaka.5ch.net/test/read.cgi/php/1624434493/550

>>649
俺は欠番しないシステムにすべきってお前の主張の前提である「bigintは現実的な時間であっという間に枯渇する」に同意してないので、その根拠が示されるまでは先に進むつもりはないぞ。示してくれたら、その欠番しないシステムの話も教えてあげるよ。

>>650
残念ながらその点に関しては標準ではサポートしていない　以下ドキュメント抜粋

Eloquentは、それぞれのモデルがその主キーとして役立つことができる、少なくとも１つの一意に識別される「ID」を持つ必要があります。
Eloquentモデルは「コンポジット」主キーをサポートしていません。しかし、テーブルの一意に識別される主キーに加えて、データベーステーブルに追加のマルチカラム、
ユニークなインデックスを追加することができます。

複合主キーを使いたかったらmopo922/LaravelTreatsというライブラリを別途インストールする必要がある

>>650
eloquentでは採用してないが、クエリビルダで補完できるってのはすでに上で説明してあるんだけどなー。

>>647
何しれっとuuid増やしてんだよw
まず知らなかったです、uuid追加しますって言えよ

>>650
正直それについては反論できません・・・・・・・・・・・・・・・
githubのissueに複合主キーサポートしてくれよって要望が追加されたけど
結構揉めた挙句、複合主キーはシステムに必要ないとか言われて却下された

>>659
オートインクリメントおじさん、自演は恥ずかしいからやめよう無い。laravelerならクエリビルダ知らないやつはいないから、そういう間抜けなコメントはしないんだわ。

>>660
http://github.com/laravel/framework/issues/5355

>>659

そら、そうでしょうよ。
だってLaravelerって>>655-658みたいな睾丸がムチムチなバカばっかなんですもん。

世の中って、バカほど声がでかいから、マトモな事を言う人間は苦労するんすよ。

■マトモな人間とバカLaravelerとの戦争

マトモなシステムを導入した企業

「おい、型番 JS32S と PS932J の売上レポートを提出しろ」
「はい！」

Laravelを導入した企業の

「おい、ID 18474656783899542 と 4892072618349042 の売上レポートを提出つしろ」
「え？　何ですって？」

Laravelerの主張

「だって、idと製品番号が同じ必要は無いじゃないですか！』

マトモな人間の発想

「お前、同じ製品番号の商品が複数あると思ってる？　製品番号をIDにするだろ？　普通」

Laravelerの主張

「だって、Laravelはauto_incrementなIDしか持てないんですよ！！」

マトモな人間の発想

「そんなポンコツ、何で採用した！？」

>>661
いや、それeloquentの話な。ちゃんとissue理解してないのか？まさかとは思うけど、お前マジでlaravelerなのにクエリビルダ知らないのか？

laravelとしては複合キーはクエリビルダで対応可能。eloquentではサポートしていないってだけ。

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

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

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

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

『N+1問題』とか寝言を言って喜んでいるLaraveler達…。

今、2021年っすよ？

eloquentではサポートしていないって『だけ』。


……やてｗｗｗｗｗｗｗｗ　ちょーうけるｗｗｗｗ

今、2021年っすよ！？えｗｗｗｗｗｗ

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

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

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


> 複合主キーでなくとも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の思想に、明らかに反してるだろ。本末転倒なんだよ、お前の言ってる事。

>>665 をしようとすると、『ぐるぐるSQL』になってしまう、

The Laravel ！！！

えぇぇ！？　今、2021年っすよ！？　マジっすか！！！！！？？？？ｗｗｗｗ

草

>>670

それ、前スレの引用だったっけ？　

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

いわないいわないｗｗｗｗｗ
Laraveler、マジ、脳みそ、腐ってるｗｗｗｗｗ

> RDBの思想に、明らかに反してるだろ。本末転倒なんだよ、お前の言ってる事。

してないしてないｗｗｗｗｗ
そういう事をするために開発されたのがRDBｗｗｗｗ

まじ、Laraveler トチ狂ってるｗｗｗ

草

草

草

草

草

草

草

>>669

おっす！　ぐるぐるSQL君！ｗｗｗｗ

こんなオートインクリメントしか使えないフレームワークが業界シェア1位って終わってるな
それとも他のPHPフレームワークがもっと終わってるから一番ましなのがLaravelなのか？

それで結局、「bigintは現実的な時間であっという間に枯渇する」という主張の根拠は、今日も示せないってことで良いかな？

確か前スレで、『そのエロなんたらとクエリビルダ、併用出来ないの？』って聞いたら

『学習コスト考えろ！』とか言っていたのがLaravelerだったのに、

さっき『複合プライマリキー出来ないんスカ？』って聞いたら

『クエリビルダがあるだろ、ボケ！』と、

謎の言葉を吐く、Laraveler ｗｗｗｗ

もうこいつら、論理性皆無ｗｗｗｗ

>>684
学習コスト考えろなんて話見たことないけど。レス番号示してくれる？

>>682

違います。終わってる奴らでもなんとなく使えるのが、
Laravelと、Wordpressなのです。

バカ御用達の二大巨頭なのです。

前スレで、eloquent禁止にしてるって企業はあるって話はしたけどね。当然ActiveRecordによる制約を受けたく無いからそういう指針になってるはずで、併用できないのか？てのはかなり愚問だと思われる。

>>685

http://medaka.5ch.net/test/read.cgi/php/1621940461/807-808

>>687

おい、愚問なのに、なんで複合プライマリキーならクエリビルダ使えとか言い始めてんだ？
脳みそ、涌いてんのか？

Laravelerの特徴

・.envをコミットする
・node_modulesをコミットする
・vendorをコミットする
・package-lock.jsonをコミットしない
・composer.lockをコミットしない
・認証にユーザIDを利用したいのでemailカラムにユーザIDを入れる
・認証にユーザIDを利用したいのでvendor直下のファイルを修正する
・トランザクションや排他を知らない
・複合プライマリキーはRDBの思想に反している ←NEW

>>688
あー、俺以外のやつが勝手に横からレスしてたのか。そりゃ確かに俺の記憶に無いわけだ。

>>689
ActiveRecordてパターンとは相性悪いのが複合プライマリーキーだから、クエリビルダ使えて主張するのは当たり前の話だよね。前スレの790に書いた通りだぞ。よく読め。

790 名前:nobodyさん [sage] :2021/06/21(月) 21:09:46.99 ID:???
アプリケーション中心の設計ならEloquent、データベース中心の設計ならクエリビルダ使えるのがLaravelの良いところなんだが、まぁアホには理解できんだろう。

9223372036854775807

1msごとにリソースを消費するとして9223372036854775
ユーザーが100万人いるとして922337203
※この時点でまだ1秒しか経過していない

1日は3600秒だから256204

256204日は701

つまり、たった701年でbigintは枯渇してしまう！！

さらにCPUが64スレッドだったとしたら20年だ

20年で枯渇するのではれば十分現実的だと言える
しかも20年後はきっとスレッドは64よりもっと十分に大きいだろう

以上のことからbigint枯渇は現実的かもしれないといえる！

逆の視点から考えてみよう
64bit整数とはつまり8バイトだ

ただの連番IDに8バイトも使うのだ

レコードが1兆あったとすれば8兆バイトのストレージが無駄に使われるのだ
これはbigintが枯渇するよりもストレージの枯渇を心配したほうがいいのではないか？

>>692

だからわたしが、何度も何度も再三に亘って『それ、併用できないんすか？』って聞いたのに、
おそらくはずっと『bigintが枯渇ウキ―！』って言ってるバカが、全く答えようとしなかったんだよその問題。お前なのかな？　よーわからんけど。
あんとき普通に『適材適所で使い分ければイイんじゃね？』って言ってれば良かっただけなのに、
Laravelerは見ての通りのアホ揃いだから返答をごまかし続けたんだろ。

Laravelerは、FWが無ければ何も出来ないアホ揃いだって事をまず認めて、そっからスタートすべきだな。

>>670
VIEWを使えばいい

>>663
主キーを製品番号にした場合、製品番号の変更できない

>>694
>レコードが1兆あったとすれば8兆バイトのストレージが無駄に使われるのだ
>これはbigintが枯渇するよりもストレージの枯渇を心配したほうがいいのではないか？

いや、『欠番が出ることが問題っすよ』って話だから。
8兆バイトは費やさないね。

極端に言うと、1の次が922京で、オーバーフローして3レコード目のINSERTでエラー、
ってのもあるよー！って問題。

>>697
>主キーを製品番号にした場合、製品番号の変更できない

変更すればいいし（なんで変更できないと思ったのか理解できない）
製品番号変わったら、それは別の製品。

社会人ですか？　本当に？

>>628
「欠落しない連番の発行方法」だけだと要件が足りない
欠落を定義してください