>>599

そういうのは、Laraveler園児達が、
何事もなかったかのように欠番しない連番システムを作れるようになってからホザいてくださいねー？

>>598
偽計業務妨害

システム構築において利用者が法に触れる方法で利用する事まで想定する必要はあるのか？
・ローカルなシステムであった場合はもはやシステムの問題ではなく従業員の故意性や品性の問題
・パブリックなシステムであれば必要最低限の対策は必要だが完全である必要はない
例えば公園のベンチで寝ていたとして髪の毛を抜かれたとしよう。髪の毛が枯渇するまで起きなかったのが悪いのか？抜かれるようなところで寝ていたのが悪いのか？
それとも髪の毛を何らかの方法でロックしておくべきだったのか？
いや、明らかに髪の毛を抜いた者が悪いだろう

システムも同じで犯罪者は警察に捕まるべきなんだ

SELECT FOR UPDATEなんて使ったら他のユーザーが採番中はロックかかってるからシステムがフリーズしちゃう

Laraveler馬鹿すぎて草

零細に務めてるやつってやっぱ馬鹿しか居ないよな

>>602
> 犯罪者は警察に捕まるべきなんだ

犯罪者は警察に捕まるべきというのと、
じゃぁ、脆弱なシステムを作ってもいいでしょ？
というのは、別の問題だと申し上げました。

>>606
まずbigintを使ったauto_incrementがどう脆弱なのか説明してくれるかい？未だに、現実的な時間であっという間にbigintを枯渇させられるってバカな主張の根拠が示されていないのだが？

>>607

その前に、Laravelerは欠落しない連番を発行できるくらいにはなりましょう。
システム開発者として、低レベル過ぎますよ？

というか、あなた、必死ですねｗ

>>608
欠番を作りたくないという背景がよく分からんけど、欠番作りたくないなら削除機能を設けないようにするだけじゃね？

>>608
低レベルなのはお前だよね。まともに計算も出来ないから、現実的な時間であっという間にbigintを枯渇させられるなんて愚かなことを言ってしまうんでしょ？違うかい？

疑問なんだがなんでみんな意地を張ってるんだ？
欠落しない連番の発行の仕方がわからないのであれば素直に「お願いします教えてください」って言うだけだと思うけど
自分より技術に詳しい人がせっかくスレに来てるんだから教えを乞うべきだよ

欠落しない連番の発行方法についてだけどみんなは

・Laravelで実装可能
・Laravelでの実装方法はわからないが素のPHPでなら実装可能
・そもそもわからない

どれになるんですか？

「連番で」
なんて要望が出たらそれにかける時間が無駄と却下するから。
その要望に意味が無い。

>>613
連番すら実装できねーのかよ・・・

>>614
そんなくだらない発言する奴は干す

顧客「連番でチケット番号発行するシステムを作ってほしいんだけど」
>>614「くだらない要望持ってくる客は消えろ　二度と来るな！！」

Laravelerマジかよｗ

>>617
お前安価ミスってるぞｗ

>>617
ブーメラン

>>611
お前の主張は、bigintは現実的な時間であっという間に枯渇するから、連番システムを使うべきって話だったよね？
それに対してlaravelerは、計算も出来ない馬鹿がおかしなこと言ってるな？てことで、枯渇するという根拠を示せと言っている。分かるか？

>>613
> 「連番で」なんて要望が出たらそれにかける時間が無駄と却下する

あなた、その程度の事に、一体どれだけの時間を必要とするんですか？
何の時間ですか？
1. 方法を調べるための時間
2. 方法を実装するための時間
3. 間違いなく連番が発行される検証するための時間

えぇぇ…。

>>612
それはテーブル設計の話だから、FWや言語に依存すると考えるのが頭おかしい。

>>610
> 低レベルなのはお前だよね。
いいですか？　>>610よ、よく見なさい。
これが、Laravelerの実態なのです。
これほどまでに、低レベル。
お前がどれほど頑張ったところで、Laravelerは最低限のIT技術知識を持ち合わせて居ないのです。

>>622
誤魔化さなくて良いので、早くbigintが枯渇するという根拠の提示を頼むわ。
ちなみに前も書いたけどbigintは920京で1年は3153万秒な。

>>621
> それはテーブル設計の話だから、FWや言語に依存すると考えるのが頭おかしい。

そんな当たり前の事すら分からないから、
少し前のレスでRDBMSのバージョンや設定の話に盛り上がり、
『デッドロックしてしまう！』などと、訳のわからない妄言を吐き合うのが、
The Laravelerなのですよ。

>>623
> 誤魔化さなくて良いので

一生懸命ごまかしているのは、あなた一人。
可愛そうなLaraveler。

>>624
それもすでに書いた通り、select for updateを使った実装の問題点の指摘だから別におかしいことではないよ。お前は開発したことないから理解できないようだけと。

> 1年は3153万秒な。

Laravelはあまりにも遅いので、物事の尺度は『秒』です。

なんか、話をはぐらかす人がいるので再掲しますが、
欠落しない連番の発行方法についてだけどみんなは

・Laravelで実装可能
・Laravelでの実装方法はわからないが素のPHPでなら実装可能
・そもそもわからない

どれになるんですか？

>>627
バカでも分かるように秒にしてあげたんだが。仮にμ秒だとしても単にそこから100万倍になるだけだから、枯渇させるには程遠いよ。

Laravelerは、
排他処理を実装できず、AUTO_INCREMENTしか知らない為、
『キャンセルが発生したら欠番して番号が飛ぶ』事を恐れ、
『あー、INTで足りるか？　BIGINTにしちゃうー？』
などと、実際のユーザ数に伴わない賭博的設計でデータ型を取り決め、
『BIGINTなら絶対足りるっしょ！』などと、
おおよそ、コンピュータを使った仕事に携わっているとは思えない論理で
システム開発の真似事をして日銭を稼ぐ
どうしようもないロクでなし達のようです。

>>629 が、Laravelがあまりにも遅い事を、認めました。

>>629 『BIGINTなら絶対足りるっしょ！』

まさしく、この通りの低次元さです。

だから、欠落しない連番の発行方法についてだけどみんなは

・Laravelで実装可能
・Laravelでの実装方法はわからないが素のPHPでなら実装可能
・そもそもわからない

どれになるんですか？　答えてくださいっ！

>>631
ふむ。ついに日本語自体通じなくなったか。とりあえず出直しておいで。次はbigintを現実的な時間で枯渇させられるという主張の根拠を用意してきてくれよな。

何故か一人だけ勝ってる気になってる >>634 が、ちょーうけるｗｗｗｗ
Laravelerは欠番しないIDすら発行できないのにｗｗｗ

Q『Laravelerに質問です。ユニークな番号はどのようにして発行しますか？』

A『(string)Illuminate\Support\Str::uuid()->getInteger();
　知らないくせにイキるなよ』

Q『それはどのような番号になりますか？』

A『172787912317449007508377903887728658844！（ドヤァ！）』

Q『帰ってもらって大丈夫です』

>>630
Laravelも昔はbigint使ってなかったんだけど
「デフォルトでbigintにしておけば安全だよね」とかいう意味不明なissueが立てられて採用された結果
デフォルトでbigintのオートインクリメントが使用されるようになった
LaravelerどころかLaravelのコミッターもアホですね

これが、Laraveler。


http://medaka.5ch.net/test/read.cgi/php/1621940461/
>826nobodyさん2021/06/22(火) 09:55:34.70
>シークエンスでオートなnumberingをするようなDBのデファインを使うのは優れた方法の1つ
>重複しないことをDBMSが保証してくれる上にパフォーマンスもよい
>よく自動採番の欠点として例示されるのがマスタ画面で新規登録する際
>登録時に採番した番号を表示できない、表示したらキャンセルした場合に欠番が出るなんて言うけど
>エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ

>>636
ユニークな番号をどうやって発行するの？という質問に対してはその回答で正解でしょ
ユーザが覚えやすいとか人間が扱いやすいとかそういう条件がつくんだったら不正解だけど

>>637

結果、LaravelerはBIGINTなauto_incrementが無いと何も出来ない作業工に成りはて、
今は、何としてでもその牙城を守る事だけが魂の拠り所に…。

で、LaravelerはBIGINTなAUTO_INCREMENTが頼みの綱だから、

『貴方のチケット番号は 369872048178498328 です』

とか、キチガイみたいな事言い始めるんだよなｗｗｗｗｗ

>>639
> その回答で正解でしょ

もう、Laravelerって、感覚からしてトチ狂ってるロボなんだよね。
正解なわけないじゃん。

こんなロボ共に絶対に仕事発注してほしくないわ。

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

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

Laravelを導入した企業の

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

Laravelerの主張

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

マトモな人間の発想

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

Laravelerの主張

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

マトモな人間の発想

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

面白いねぇｗ　Laravelerの発想、面白いねぇｗｗｗｗ

>>635
そんなつもりは無かったけど、そう思ったということはお前自身が心のどこかで俺に負い目を感じたからだろう。可哀想に。

LaravelがオートインクリメントIDしか持てないってなんの話なんだ？
別にデフォルト設定がオートインクリメントなだけであって
オートインクリメントIDをオフにもできるし、数値だけでなく文字列も可能だけど

いいですか？　みなさん。

Laravelerは、auto_incrementとuuid()が無いと、

な　に　も　で　き　ま　せ　ん　！！！！

Eloquentは、各モデルの対応するデータベーステーブルにidという名前の主キーカラムがあることも想定しています。
必要に応じて、モデルのprotected $primaryKeyプロパティを定義して、主キーとして機能する別のカラムを指定できます。
さらに、Eloquentは、主キーが増分整数値であることも想定しています。これは、Eloquentが主キーを自動的に整数にキャストすることを意味します。
非インクリメントまたは非数値の主キーを使用する場合は、モデルにpublicの$incrementingプロパティを定義し、falseをセットする必要があります。
モデルの主キーが整数でない場合は、モデルにprotectedな$keyTypeプロパティを定義する必要があります。

>>645-646

相変わらず、欠番しない連番の発行方法については何一つ語りません。

かわいいですねぇｗ

>>648

へぇ。なんか長いしごちゃごちゃ言ってるんで読んでないですけど、

で、複合プライマリキーは？

業務システムでは必須ですよねぇ？