@joukan_jakusha 別ツイでも書いたけど、ヒューマンエラーは避けるべきやからな。
オート+ユニークでやっても、設定ミスってたらそもそもやし。
@joukan_jakusha ん?普通に無用なリスクは避けましょうってだけなんやが?
そういうヒューマンエラーの可能性がある箇所はなるべく減らしていくべきやろ。
↑
明らかに出来の悪いエンジニア用のAUTOINCREMENT機能の全否定である。
@joukan_jakusha Auto_incrementの設定ミスってたらダルダルイングリッシュなので、何も考えなくていいUUIDにするのだ。
↑
とにかくUUIDを使わないといけないらしい。
@joukan_jakusha あとは、intの最大値を考えると上限に到達しないとは思うし、intで足らんならBIGINTに変えれば済む話ではある。
とはいえ、UUIDが128bitに対してBIGINTは64bitなので特段コストかからんのならUUIDでも別に良いとは思われ。
↑SQLiteのAUTOINCREMENTの上限は1.6京なのに急に21億/42億ということにしだす
@joukan_jakusha あとは、そこまで実装コストかからんのに、わざわざ128bitで生成するUUIDを捨ててintにしますってステークホルダーに説明しても「は?」って言われるだけやしな。
↑
1.6京の数字よりもUUIDの方が有用であると感じるステークホルダーしか世の中にはいないらしい。検索コストだけだろ…
@joukan_jakusha テストコードでダミーデータ作れば良く無いか..?
ユニーク制約のテストでやりたいのは、すでにあるIDと同じやつ突っ込んだ時に落ちるのを確認できればええんやし。
あと、この程度で赤っ恥になってたら、awsのクソ翻訳ドキュメントとか読んでられへんで....
↑UUIDの衝突は単体テストだけやれば良いらしい。システムテスト、ランニングテスト、フィールドテストでのリソース開放確認とかはしなくて良いそうな。気楽でいいな。