PostgreSQLアンチパターン自動採番される疑似キーを手動で入力する

SQL全般の話ではなくPostgreSQLの話です.

に関連するアンチパターン.

運用の問題なのでアンチパターンではないかもしれません.

問題

id bigint not null default nextval('foo_id_seq'::regclass)

のような自動採番される人工キーに対して, 自動採番のシステムを通さないで, id手動で指定してinsertで入力してしまうと, 次のinsert時にIDがユニーク制約違反になってエラーになります.

もちろんRDBMSにもよるのでしょう. 今回発生したのはPostgreSQL上での話です.

PostgreSQLは自動採番する時に自動採番用インデックスデータをインクリメントしてその値を使うので, 自動採番システムを通さないでidを入力してしまうと次回の入力時にinsertがエラーになってしまうんですね.

そしてシステムは止まり, 決済は中途半端な状態で発行されてしまい, ユーザからの信頼は消失します.

insertしたのは私ではありませんが, 任せたのは私ですし, ユーザにとっては関係ないと思うので, 非公式で何もわからないと思いますがわかる人向けに謝っておきます. ごめんなさい. これは他の人がやらないための業界向けの技術記事であり, 謝罪記事ではありませんが, 重ねて謝っておきます.

このことがわかっていれば問題はない.

まともな解決策.

しかしそもそも人がinsertしなければいけない状況が発生してしまっていたからこの問題が発生したので, それは解決策になっていない.

人類を滅ぼすという近似解もあります.

自動採番にインクリメント数値を使っているから手動で入力されてしまう.

初めからUUIDを使っていれば手動で入力されることはない.

万一uuidgenを使うほど半端にリテラシーが高い人が居てもUUIDなら後から入力されても衝突しないので無問題.

疑似キーを自動で付加するような軟弱なフレームワークを使わないという硬派な選択.

何気ないリソースのURLをどうやって決めるんですか, 無理では…?

ただ, URLを提供しないようなリソースには一々idをつける必要はないかもしれません.

既存のSQLアンチパターンであるIDリクワイアドにあるように, 一々idを付加するのは再考する必要があるでしょう.

しかし今回はマッパーが自動的にidを付加していたので, それに逆らって設定で消していくのも一々しんどい.