大学行かなかった理由、研究するつもりはないってのもあるけど。
大学は研究機関であってくれ。社会に出たときのための対策をするのは専門学校で十分。

弊社、どう見てもPOAなんだ。データ構造が。
DOAじゃない。
DOAじゃないからDBをリレーションする必要がないので、高度なSQLを書くよりも機械的に全レコードにid振ったらええやんってなるんだ。
たしかに、複合ユニークカラムのデメリットは、適当なプログラムを書くと簡単に死ぬことだ。

ごろうさんは大学じゃなくてコンピューターの専門卒なんだけど、
専門学校に行った理由は「情報系の仕事をするにあたって、一度体系的に勉強してみよう」って思ったから。
正直あまりに低レベルな内容の授業で、どうせ行くなら別の学校がよかった…って思ってたんだけど、今の弊社を見てみると、なるほどそのレベルから教える意義は、わからんでもないなと思った。

（たぶん主キーのユニーク制約を知らないエンジニアがいる）

…弊社、その話で「ユニークになるものがないときはIDカラム作ればいいか」って話になったけど
ん？RDBって、単一か複合かは問わず、必ずユニークにならないとデータ格納できないよね？
なんでユニークになるものがない可能性が…？

たとえば「会員」テーブルにorder byで住所の都道府県順にしました！とかだと
同一都道府県の会員が複数いたら、その中で誰が最初に来るかは実質ランダムなので
orderはユニークになるようにしましょうね

どこでこの知識知ったんだっけなあ
興味本位だったか、体系的に習ったんだったか…。

個人的には当たり前だと思ってたけど、弊社エンジニアの9割は知らなかったみたいなので、何事も常識を疑うべきだなと思いました。

【DB】orderを指定しない場合のselect取得順
https://shikiyura.com/2019/08/select_not_specified_order_clause/

Orderを指定しないと出てくる順は実質ランダムなんよね。
全く同じ条件下で全く同じクエリを投げたらほぼ同じ順で帰ってくるけども。
offsetとかを使うと混乱が起きる。

@gorou12
総トゥート数： 2466
　　　前日比： +4
---
いかすきー： 18360(+1)

#toots_alert