今のうちにメモしとくか。秒単位の時刻じゃなくてUUIDを使えば論をかざすDevenMiveなるツイ垢の主なツイート
・UUIDにUNIQUE制約付けてinsertでエラーか見て振出せば良い に対してそんなことしなくてもAUTOINCREMENTが使えるDB使えばいいだけって送ったあとのリプ
→AUTOINCREMENT使ったとしても設定し忘れるから意味ない に対してAUTOINCREMENT忘れるような奴はUNIQUE制約でシノニムレコード引っかかった時のリトライ処理を書けない
そもそもAUTOINCREMENT使った場合はinsertのカラムが足りないので設定を忘れたら普通に動かないはず(なので絶対に気付く)
@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の衝突は単体テストだけやれば良いらしい。システムテスト、ランニングテスト、フィールドテストでのリソース開放確認とかはしなくて良いそうな。気楽でいいな。
