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

**nobodyさん** · 2021/05/25(火) 20:01:01.50

Laravel
ウェブ職人のためのPHPフレームワーク

本家
https://laravel.com/

git
https://github.com/laravel

動画チュートリアル(英語)
https://laracasts.com/

和訳ドキュメント
http://laravel.jp/

※前スレ
【PHP】Laravel【フレームワーク】 Part.5
https://medaka.5ch.net/test/read.cgi/php/1618535648/

**nobodyさん** · 2021/06/20(日) 16:20:43.33

>>733
読み返してみたのですが

> コントローラではない所で更新

この表現は適切じゃなかったですね

> 独立した処理として更新

が適切かもしれません

**nobodyさん** · 2021/06/20(日) 17:43:02.03

N+1問題、Laravel8の最新バージョンだと回避できるようになってる。N+1になる処理を実行しようとすると例外を発生させられるようになった。

**nobodyさん** · 2021/06/20(日) 19:14:58.36

お前ら、マジで何やってんの？

**nobodyさん** · 2021/06/20(日) 19:20:55.26

>>735
マジで？それはドキュメントのどこに書いてあるの？

**nobodyさん** · 2021/06/20(日) 19:34:42.48

>>737
マニュアルにはないかもしれないけど
この辺じゃないかな？
https://twitter.com/taylorotwell/status/1395087054254526474?s=21
https://github.com/laravel/framework/pull/37363
https://twitter.com/5chan_nel (5ch newer account)

**nobodyさん** · 2021/06/20(日) 19:46:37.88

>>737
すでに上で出てるけど、こっちの方が分かりやすいかな。
https://laravel-news.com/disable-eloquent-lazy-loading-during-development

**nobodyさん** · 2021/06/20(日) 19:47:49.94

マニュアルだとこれ
https://laravel.com/docs/8.x/eloquent-relationships#preventing-lazy-loading

**nobodyさん** · 2021/06/20(日) 21:16:40.26

>>725
速攻論破されて草 >>738-740の内容知らなかったのかな？

**nobodyさん** · 2021/06/20(日) 21:42:57.75

俺はまだ論破されていない　>>738-740はN+1の回避策を提示しただけであって
FW側で回避できるという証明にはならない

**nobodyさん** · 2021/06/20(日) 21:52:49.79

ちょっと言っている意味がわからないです

**nobodyさん** · 2021/06/20(日) 21:53:07.92

>>598
いや、別に論破とかどうでも良いんだが。N+1の実装したら例外出て便利になったっていう情報知らないぽいから教えてあげたかっただけ。

あとFW側で回避したいなら、modelのwithプロパティ使っとけば確実だと思うけどね。ただこれ使うと余計なテーブルアクセス増えてしまいがちだから、不要な時はwithoutとかのメソッド入れなきゃダメで、それはそれでだるい。

**nobodyさん** · 2021/06/21(月) 00:54:44.77

だからモハメドの話をちゃんと聞けって
Laravel使っててモハメドの話聞いてないとかありえないぞ
https://youtu.be/213aEudaumk

**nobodyさん** · 2021/06/21(月) 09:50:26.59

N+1問題とか、何やってんだろうなぁって思ったら
エロなんたらがActiveRecord型だからっつう事か？

アホな事やってんなぁ…。

ActiveRecord型はJOINが表現しずらいから使わんのよね。
無駄な努力をご苦労さん。

**nobodyさん** · 2021/06/21(月) 10:19:15.52

近頃のFWはだいたいがActiveRecord型だし、特に無駄な努力なんてしてないけどな？DataMapper型しか使ったことないアンチオートインクリメントおじさんは、いつまでLaravelスレで粘着するのかね？

**nobodyさん** · 2021/06/21(月) 10:48:42.22

ActiveRecord型は表現が冗長でミスを誘引しやすい
特に初心者にとっては記述する動機になりづらく成長の阻害要因

JOINで書くよりN+1で書いたほうが表現がスマートなのが問題なんだよ

**nobodyさん** · 2021/06/21(月) 10:50:58.39

Laravel以前はCakeしか使ったことないからN+1なんて知らんかったわ
ここ数日初めてこのスレで勉強になった

**nobodyさん** · 2021/06/21(月) 11:28:23.03

JOINで書くってDBファサードからjsonメソッド使って書くって事？
生のSQLでjson使って書くって事？

**nobodyさん** · 2021/06/21(月) 11:30:35.35

ベテランRailsエンジニアたちがN＋1でハマってるのみて何をもがいているのか不明だった
そしたらLaravelでもハマる奴らも続出していたんだな

**nobodyさん** · 2021/06/21(月) 11:35:51.07

いや、ベテランはハマらないぞ。さすがに。DBアクセスのロジック書いたら、普通に生成されるSQL確認するから、そこで気づく。

**nobodyさん** · 2021/06/21(月) 11:37:18.75

あとjoinガーて言ってる人、雑魚はinner joinとouter joinを使い分けられないという点に気づいていないと思う。

**nobodyさん** · 2021/06/21(月) 12:33:16.81

生SQLとかDBの仕組み的なことを知らないとハマるんだろうね
たしかにFWがうまくやってくれるもんだと思ってたらそこまで考えない
SQLを作るための仕組みっていうのを知ってたら中間出力であるSQLはどうなってるのか気になるんだろうけど
意識しなくて済むような仕組みだからね

**nobodyさん** · 2021/06/21(月) 14:13:34.84

>>750

DataMapper型でクエリビルディングして書くって事

正直、Railsで失敗してんのに敢えてActiveRecord型を選ぶとか、頭おかしいとしか思えん。
だからプライマリキーはidのオートインクリメントです、
復号プライマリキーは設定できません、みたいなトチ狂った設計になっちゃうんだよ。

10年以上、全く成長しないよな世間の奴らって。

**nobodyさん** · 2021/06/21(月) 14:14:32.66

なんだこりゃ？　脳みそ腐ってんじゃね？　こいつ

753nobodyさん2021/06/21(月) 11:37:18.75ID:???
あとjoinガーて言ってる人、雑魚はinner joinとouter joinを使い分けられないという点に気づいていないと思う。

**nobodyさん** · 2021/06/21(月) 14:19:54.78

いや、お前らがActiveRecord型しか知らないんだろｗｗｗ
DaoもActiveRecordも同じ『JOINがたマトモに表現出来ません』問題で失敗してんのに、
なんで敢えてActiveRecord型選んじゃうっすか？ｗｗｗ

学習しましょうよ、せんぱーいｗ

747nobodyさん2021/06/21(月) 10:19:15.52ID:???
近頃のFWはだいたいがActiveRecord型だし、特に無駄な努力なんてしてないけどな？DataMapper型しか使ったことないアンチオートインクリメントおじさんは、いつまでLaravelスレで粘着するのかね？

**nobodyさん** · 2021/06/21(月) 14:21:17.36

アンチオートインクリメントおじさんが荒ぶってらっしゃる

**nobodyさん** · 2021/06/21(月) 14:21:18.84

やべぇ、流石に草生えまくり過ぎて、誤字・誤変換だらけになってるし。

**nobodyさん** · 2021/06/21(月) 14:27:07.58

アホはトレードオフって言葉を知らないので、ある側面だけをみてActiveRecordは失敗とか言っちゃうんだよなー。
そういえば前に、ActiveRecord自体知らなくて、1テーブル1モデルなんてありえねーとか言ってた恥ずかしい奴がいたな。

**nobodyさん** · 2021/06/21(月) 14:32:26.85

>>760

何言ってんだろうね、このバカは相変わらず。

じゃ、他のORMに比べて、他にどんなメリットがある？
お前、マジでActiveRecordしか知らないんじゃん。

**nobodyさん** · 2021/06/21(月) 14:33:53.71

>>760

ってか、『1テーブル1モデル』って、なんすか？ｗｗｗ

もしかして『1テーブル1クラス』の間違いっすか？ｗｗｗ

**nobodyさん** · 2021/06/21(月) 14:35:29.37

わざわざDataMapper型に触れておいたのにこれだもんなぁ。アンチオートイクリメントおじさんの頭の悪さは相変わらずで。自覚ないからつい人を見下しちゃう癖もそのままかー。可哀想。

**nobodyさん** · 2021/06/21(月) 14:38:21.20

前スレ。ブーメラン乙。

>>937

人の話聞いてんのかな？ ModelはDBにアクセスする物じゃねぇんだから、
Modelとテーブルが１対１なわけねーーーーーーーだらーーーーーーーーーー！
937nobodyさん2021/05/23(日) 18:01:50.48ID:???
他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？

**nobodyさん** · 2021/06/21(月) 14:42:06.29

オートインクリメントおじさん、書きっぷりが独特だからすぐわかる

**nobodyさん** · 2021/06/21(月) 14:51:04.66

>>764

何いってんだこのノータリンは…。日本語読めないのか…orz
それを『1テーブル1モデルなんてありえねー』って読むのか、バカって。

「１つのモデルで取り扱うのが１テーブルだけだなんてあり得ない」って書いてあるんだぞ？
なんでテーブルが主語になってんだよ？
脳みそ腐りすぎだろ、かんべんしてくれよ。

というか、937が
「他のテーブルとのjoin操作までModelに入れるのは」
って言ってんだぞ、そっちをつっこめよ。
そのバカ、『Model=DBにアクセスする場所』って思ってるって事だぞ？
なわけねぇだろ。

お前らって、本当にプロのエンジニアなの？　素人だろ？

**nobodyさん** · 2021/06/21(月) 14:53:50.03

>>765

はいはい、凄い凄い。

テンプレエンジンが独自Bladeです、の時点で『マジか！？』と思って避けてたけど、
Railsと同じ失敗するとか、２度めの『マジか！？』だな。

ほんと、学習しねぇよなぁ…。

**nobodyさん** · 2021/06/21(月) 14:55:27.17

>>763
> わざわざDataMapper型に触れておいたのにこれだもんなぁ。

聞かれた事に答えずに遁走っと。

尋問内容：
じゃ、他のORMに比べて、他にどんなメリットがある？
お前、マジでActiveRecordしか知らないんじゃん。

**nobodyさん** · 2021/06/21(月) 14:58:40.65

というか、これが全てだろ。
お前ら、マジで、いつまでおんなじ所ぐるぐる回ってんだよって話。

751nobodyさん2021/06/21(月) 11:30:35.35ID:???
ベテランRailsエンジニアたちがN＋1でハマってるのみて何をもがいているのか不明だった
そしたらLaravelでもハマる奴らも続出していたんだな

**nobodyさん** · 2021/06/21(月) 15:05:20.06

アンチオートインクリメントおじさん、きっと仕事で誰とも組んでもらえなくて、チーム開発したことも無いんだろうな・・・。

**nobodyさん** · 2021/06/21(月) 16:01:02.96

結局、Laravel使うプロジェクトって、
取って出しの簡単な物しか作ってないって事なんだよな。
業務システムみたいに復数テーブルと都合させて～みたいな処理はやらない。
そういうのしかやった事ない奴がLaravelまんせーしてる。

まぁ、そういう簡単な用途ならいいんじゃねぇの？

**nobodyさん** · 2021/06/21(月) 16:02:28.23

もう、呆れ果てて誤変換しまくり。

“複数テーブル突合させて～”。

**nobodyさん** · 2021/06/21(月) 16:10:23.74

別に何のORMが使いやすいとか
DataMapperがとかActiveRecordがどうのとかそういうのは個人の趣味趣向だから好きにしてって思うんだけど
laravelで使う上で色々なライブラリやFW自体がeloquentを使う前提で作られてるのに
それを外してまで他の仕組み導入するメリットってあるのかな？

**nobodyさん** · 2021/06/21(月) 16:11:57.88

クエリビルダ知らずにドヤってて、見てるこっちが恥ずかしいわ。

**nobodyさん** · 2021/06/21(月) 16:23:48.14

laravelに別のORMを導入した時点でメリットがあるのはプロジェクトじゃなくて、自分になるんじゃない？
その証拠に規模や用途の話が全く出てきてないよね？
全てのプロジェクトに対してのベストプラクティスが一つならどっちがいいなんて議論にならないはずよね

**nobodyさん** · 2021/06/21(月) 17:43:07.60

そういうわけでN＋1くらい我慢しろ
これが不具合というわけでもないんだし

**nobodyさん** · 2021/06/21(月) 18:56:49.34

773と774で言ってる事背反してんのに>>774って頭悪いよなぁ。毎度こんな感じだけど。

クエリビルダ知らんってのもどっから出てきたんだよって話しだし、
あったらなんだよ、それで解決すんのか？、って話しだし、
アホ過ぎて頭痛くなってくる。

こういう馬鹿って、来月あたりにN+1にどっ嵌って頭かかえてそうな馬鹿さがある。

**nobodyさん** · 2021/06/21(月) 18:59:00.80

>>775
> その証拠に規模や用途の話が全く出てきてないよね？

どこに？　主語ちゃんと話そうぜ？

**nobodyさん** · 2021/06/21(月) 19:18:52.39

>>777
中規模以上のプロジェクトだとeloquent禁止して、クエリビルダで開発してたりする。まぁ、Laravel使わないのにこのスレに居座る構ってちゃんには関係無い話か。

**nobodyさん** · 2021/06/21(月) 19:39:32.60

>>779

禁止w

マジで、何やってんのあなた達w

**nobodyさん** · 2021/06/21(月) 19:46:28.53

うん？アーキテクチャを決める際にEloquentを使うか、クエリビルダを使うかの意思決定の話だぞ。
チーム開発において、好き勝手な実装を認めるわけには行かないってのは理解できるかい？
お前、アーキテクチャ設計とかチーム内の規約とか作った経験無いでしょ？

**nobodyさん** · 2021/06/21(月) 20:29:49.29

えっとさ、併用、出来ないの？　禁止って。
どうしてそうなっちゃう？

**nobodyさん** · 2021/06/21(月) 20:30:49.94

> お前、アーキテクチャ設計とかチーム内の規約とか作った経験無いでしょ？

論点ずれまくりだって事くらいは分かろうな？

**nobodyさん** · 2021/06/21(月) 20:44:58.66

Laravelを採用するやつらは周りから嫌われていることを知ったほうがいい
わざわざ失敗したActiveRecordが実装されているFWを採用している時点で何も考えていないアホなのが丸わかり

**nobodyさん** · 2021/06/21(月) 20:49:47.04

Laravel使ってるやつらって自分が楽するための簡単なツールとかそういう程度のアプリしか実装したことないだろ
実際の業務では複合主キーや複数テーブルなどの操作は当たり前だからな
それらをサポートしていないLaravelのようなFWを業務で使うことはない

**nobodyさん** · 2021/06/21(月) 20:50:42.90

Laravelって複合主キーってできないの？
マイグレーションでは複合主キーできるよね

**nobodyさん** · 2021/06/21(月) 21:00:42.76

>>783
ズレてるのはお前。そもそもLaravel使ったことないくせに、なぜこのスレに居るんだい？

**nobodyさん** · 2021/06/21(月) 21:03:35.83

>>787

おー、恒例の論点ずらしっすか。

じゃ、敢えて乗ってやると、
ちまたの皆さまがまんせーするLaravelとやらが、どれほど成長したのか見て差し上げようと思って覗いてみたら、
『まだそんな事やってたんすか！！！！』という驚きと共に、
まんせーし続ける皆様を観察して正気なのか確かめる為です。

こんな感じで宜しいでしょうか？

**nobodyさん** · 2021/06/21(月) 21:05:01.93

>>788
つまり構ってちゃんてことかwww

**nobodyさん** · 2021/06/21(月) 21:09:46.99

アプリケーション中心の設計ならEloquent、データベース中心の設計ならクエリビルダ使えるのがLaravelの良いところなんだが、まぁアホには理解できんだろう。

**nobodyさん** · 2021/06/21(月) 22:48:07.73

>>790
逆じゃない？アプリ中心ならクエリビルダ、DB中心ならEloquentだと思う

**nobodyさん** · 2021/06/21(月) 22:54:02.08

業務ロジックを込めるならSQL一発勝負のほうがシンプル

**nobodyさん** · 2021/06/21(月) 23:03:02.03

オートインクリメント君って本当にbigintを枯渇させたのかな？
それともbigint知らないでintでオートインクリメントしてたのかな？

**nobodyさん** · 2021/06/21(月) 23:07:02.06

>>791
ActiveRecord採用すると、DBの設計がアプリケーションに引きづられるって昔から指摘されてるよ。構ってちゃんが指摘する通り、複合キーも使えずサロゲートキー前提の実装になるしね。

**nobodyさん** · 2021/06/21(月) 23:07:51.96

intでも普通は枯渇しないやろw
多分そいつは何も知らないだけやと思う

**nobodyさん** · 2021/06/21(月) 23:59:27.35

intで枯渇したのってTwitterのIDぐらいしか知らないな

**nobodyさん** · 2021/06/22(火) 00:05:16.92

そもそもintって何ビットの話なんだよ

**nobodyさん** · 2021/06/22(火) 00:06:42.85

intって8ビットだっけ？

**nobodyさん** · 2021/06/22(火) 00:08:00.84

intは２バイトだろ・・

**nobodyさん** · 2021/06/22(火) 00:08:19.28

ごめん間違えた4バイトです

**nobodyさん** · 2021/06/22(火) 00:22:13.11

PHPのintは64bit
約900京まで扱える

世界の人口は78億人
どうやって枯渇したんだ？

**nobodyさん** · 2021/06/22(火) 01:39:11.62

>>801
オートインクリメント君はbigint枯渇させてからオートインクリメントは危険と思うようになったらしいですよ

**nobodyさん** · 2021/06/22(火) 02:50:07.13

>>790

速攻で否定されるアホw
あなたたち、一体何してるんすか？www

**nobodyさん** · 2021/06/22(火) 02:52:09.86

>>797-800

これがLaravelerの実態

**nobodyさん** · 2021/06/22(火) 02:58:45.33

1. intで数年で破綻する設計を実際に見た
2. 有限な値をプライマリキーにするのはおかしい

こう言ったのを、

Laravelerは頭がおかしすぎるので足して2で割ってしまい、
『bigintを枯渇させた』という、謎ワードを勝手に作り出して興奮している。

本当に頭悪過ぎ。だから2021年にもなってN+1問題みたいな下等な事でワイワイやっている。
成長というものがかけらも見られない下等な人種の集まり。

**nobodyさん** · 2021/06/22(火) 03:01:57.73

あ！今気づいた！
N+1問題って、『N isennizyuu 1 問題』だったんだ、
ちょーうけるwww

**nobodyさん** · 2021/06/22(火) 03:10:07.27

>>790

で？聞かれた事に答えないからもう一回聞くけど、

それ、併用できないんすか？www

**nobodyさん** · 2021/06/22(火) 07:00:10.38

書き方があちこちで違うと新規参画者の習熟時間が増える

**nobodyさん** · 2021/06/22(火) 07:11:23.47

>>807
マジでその質問いる？趣味でしか開発したことないの？チーム開発で規約作ったことないの？てか、「なぜ」についてもすでに回答しているよ。日本語読めないのかい？アンチオートインおじさんは。

**nobodyさん** · 2021/06/22(火) 07:11:47.61

>>809
オートイン→オートインクリメント

**nobodyさん** · 2021/06/22(火) 07:40:58.98

>>797-800

これがLaravelerの実態

**nobodyさん** · 2021/06/22(火) 07:44:10.94

PHPのintは64bit（64bit環境かつPHP7以降）
っていう話と、DBのintが何ビットかっていう話がごっちゃになってないか？

あと、有限なキーがダメって話が出てるけど
有限ではないキーなんて存在するんだろうか？

あとDBにはintは実装されてるけど使う人なんていなくて
実際はDECIMAL(NUMERIC)を使うでしょ

**nobodyさん** · 2021/06/22(火) 08:05:12.78

>>812
DBでもint使うが？

**nobodyさん** · 2021/06/22(火) 08:06:41.65

>>812
補足すると、アンチオートイクリメントおじさんは、オートインクリメントだと有限な値を使うことになるからダメだってアホな主張をしてて、それで、は？bigintなら問題ないでしょて突っ込まれて、そのあと920京はunsignedだからプログラムで読めない！とか言って失笑を買ってた。

**nobodyさん** · 2021/06/22(火) 08:57:59.61

>>809

なんか、壊れたレコードみたいになってきたなｗ

で？聞かれた事に答えないからもう一回聞くけど、

それ、併用できないんすか？www

答えると、なんか都合悪いんスカ？ｗ

**nobodyさん** · 2021/06/22(火) 08:59:43.51

>>812
>PHPのintは64bit（64bit環境かつPHP7以降）
>っていう話と、DBのintが何ビットかっていう話がごっちゃになってないか？

うん、お前らがね。

>あとDBにはintは実装されてるけど使う人なんていなくて
>実際はDECIMAL(NUMERIC)を使うでしょ

また、謎の言葉を吐き出したしｗ
Laravelerって、ここまで頭おかしいんだｗ

**nobodyさん** · 2021/06/22(火) 09:04:48.98

>>815
すでに回答済みって書いてるから、一定の知性がある生物ならログ確認すると思うよ？それともお前にはそういった知性は期待できないので、もう一度回答したレス番を示してあげた方が良いってことかな？

**nobodyさん** · 2021/06/22(火) 09:06:53.83

壊れたレコードてのは、禁止する理由説明してもなお「併用したらダメっすか？」て質問し続けるやつのことじゃないか？

**nobodyさん** · 2021/06/22(火) 09:08:54.63

>>817
>すでに回答済みって書いてるから

そういう問題じゃないって事すらわからないんだ。
よっぽど自分の頭の中だけで生きてる引きこもりなんだろうな。

で？聞かれた事に答えないからもう一回聞くけど、

それ、併用できないんすか？www

答えると、なんか都合悪いんスカ？ｗ

**nobodyさん** · 2021/06/22(火) 09:12:23.03

>>812
>あと、有限なキーがダメって話が出てるけど
>有限ではないキーなんて存在するんだろうか？

これについての返答、SQL書いてるからかなんなのか、ブロックされるな。
あのさ、VARCHAR(8)ですら、ユニーク数、幾つか計算できるか？ほぼ、出来ねぇんじゃねぇか？

**nobodyさん** · 2021/06/22(火) 09:15:42.88

>>809=817 って、自分の頭の中に組み上げた式から外れた事は一切考えられないロボ君なんだろうな。

『併用できないんすか？』って聞かれてるんだから出来るか出来ないか、答えりゃいいじゃん。

バカだよなぁ…。

**nobodyさん** · 2021/06/22(火) 09:15:57.31

>>819
会話にならねぇ。アンチオートイクリメントおじさんとの会話は俺には無理だわ。じゃーな。

**nobodyさん** · 2021/06/22(火) 09:24:54.83

・有限か有限ではないか
・必要十分か不足する可能性はあるか

これは別の問題だと思うんだよね

サービスの要件として日本人を対象とした日本語のサービスであれば目安となるのは1億2000万
これをベースに再作成や複数ID、出生率などを勘案していけばいい
日本人を対象とした商用サービスで最大レベルのものといえば電話だと思うけど
電話番号は11桁

つまり、0～9の値をとる11桁があれば日本人相手のサービスとしては十分なんだ

人類は有限であるからIDは無限である必要はない
おまえらがいきなり子づくりに目覚めて出生率が跳ね上がる見込みもない
システムの寿命、Laravelの寿命を考えると宇宙の歴史規模の余裕を持つ必要もない

つまり、11桁の数を持ち得る手法であれば必要十分なんだ

**nobodyさん** · 2021/06/22(火) 09:25:58.92

DBでintを使うってことはおまえら大企業じゃないのか

**nobodyさん** · 2021/06/22(火) 09:34:27.10

おぢさん、PDOとmysqli混ぜて使ってそう

**nobodyさん** · 2021/06/22(火) 09:55:34.70

シークエンスでオートなnumberingをするようなDBのデファインを使うのは優れた方法の1つ
重複しないことをDBMSが保証してくれる上にパフォーマンスもよい

よく自動採番の欠点として例示されるのがマスタ画面で新規登録する際
登録時に採番した番号を表示できない、表示したらキャンセルした場合に欠番が出るなんて言うけど
エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ

ただ、データベースの常識として余計なデータは不要だという事
主キー足りえる列がすでにあるのにさらにID列を設ける
これはバッドだ
氏名＋電話番号で主キーとして足るのであれば新たにID列を増やすのはパフォーマンスを落とすだけの行為でしかない
（ただ実運用上で主キーを見抜くのは並大抵ではない。例示した氏名＋電話番号が通用する場面があったとしても特殊な例外だろう）

ID列を追加するという行為は無駄な領域を確保するという事
検索速度に寄与するわけでもない主キーを追加することによってHDDの余計な領域を確保してしまう
またサーチする際のシークエンス速度もその分劣化してしまう

IDなんてせいぜい8バイトかもしれない
8バイトが1億件あったとしても8億バイトだ
RAID6構成だとしてもたった16億バイト分の領域が無駄になるだけだ

しかし、それを詰めてほんの少しのパフォーマンスアップでももくろむのが我々技術者の使命ではないだろうか

最後になったが主キーの例示でまともな例を出せなかったことをお詫びしておく

**nobodyさん** · 2021/06/22(火) 10:16:29.56

うちで作ったサービスは普通に連番でIDにしてるが表に出すユーザーIDは別のユニーク文字列を生成してる
連番だとIDで登録順がバレる、予測が簡単だから攻撃されやすいなどのデメリットがある

**nobodyさん** · 2021/06/22(火) 10:41:14.57

オートインクリメント君あまりの知識のなさに素人だということがバレちゃったね

**nobodyさん** · 2021/06/22(火) 10:48:16.11

>>826
> 最後になったが主キーの例示でまともな例を出せなかったことをお詫びしておく

わろたｗ
おまえ、これ書きたかっただけだろ

**nobodyさん** · 2021/06/22(火) 11:11:11.15

主キーなんかdefault gen_random_uuid()で十分

**nobodyさん** · 2021/06/22(火) 11:34:16.27

ナチュラルキー派って逆に時代遅れ

**nobodyさん** · 2021/06/22(火) 11:58:55.37

サロゲート使って運用楽したい
そんな理由でも良いじゃない

**nobodyさん** · 2021/06/22(火) 12:13:12.46

この前、某イベントで環境を10個作っているやべえ会社がいることに驚いた