※本記事は、Bardによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
Why you should never use an UUID as the primary key in SQL Databases - DEV Community
意訳+要約
SQLデータベースの主キーにUUIDを使ってはいけない理由
この記事は、SQLデータベースでUUIDをプライマリキーとして使用することの利点と欠点について論じています。UUIDはユニークな識別子であるため、プライマリキーとして適しているように思われるかもしれませんが、実際にはいくつかの問題があります。
重要な点は次のとおりです。
- UUIDは32ビットの整数を必要とする一般的な主キーよりもはるかに大きいため、ストレージとパフォーマンスに悪影響を及ぼす可能性があります。
- UUIDは人間にとって読みやすいものではないため、デバッグやデータベースの検査が難しくなります。
- UUIDは順序付けられていないため、特定の種類のクエリ、特に範囲検索に関わるクエリのパフォーマンスに悪影響を及ぼす可能性があります。
結論として、UUIDはユニークな識別子であるため魅力的ですが、SQLデータベースのプライマリキーとしては最適ではありません。パフォーマンス、読みやすさ、デバッグ容易さ、ストレージコスト、アプリケーション複雑さなどの問題があるため、他の選択肢を検討することをお勧めします。
具体的には、次の代替手段を検討できます。
- 整数または文字列のシーケンス
- データベースのバージョン番号
- データベースの作成日時
- データベースの作成者
これらの代替手段は、UUIDの欠点を回避しながら、ユニークな識別子を提供します。
Bardさんに聞いてみた
Ｑ：問題と言われている箇所が、適用されない場合は、主キーに使ってもいいという理解でいいでしょうか？
はい、そのとおりです。問題と言われている箇所は、次のとおりです。
- ストレージとパフォーマンスへの影響
- デバッグやデータベースの検査の難しさ
- 特定の種類のクエリのパフォーマンスへの影響
これらの問題が適用されない場合は、UUIDを主キーとして使用しても問題ありません。
たとえば、以下の状況では、UUIDを主キーとして使用しても問題ないと考えられます。
- データベースのサイズが小さく、ストレージやパフォーマンスが重要な問題ではない
- データベースの構造がシンプルで、デバッグやデータベースの検査が容易である
- 範囲検索などの特定の種類のクエリが使用されない
ただし、これらの問題が適用される可能性がある場合は、UUIDを主キーとして使用することは避けるべきです。
具体的には、以下の状況では、UUIDを主キーとして使用しないことをお勧めします。
- データベースのサイズが大きく、ストレージやパフォーマンスが重要な問題である
- データベースの構造が複雑で、デバッグやデータベースの検査が困難である
- 範囲検索などの特定の種類のクエリが頻繁に使用される
このように、UUIDを主キーとして使用するかどうかは、アプリケーションの具体的な状況に応じて判断する必要があります。
感想＋雑記
元記事だと、結構強い口調で否定していたが、場合によりけりでは？って思う。
強い口調を使ったせいで、結構コメントで反論されてた。。。
あとは、読んでて気になったのは、UUIDは重複する可能性があるからダメだというもの。
それは、UUID使わなくても重複するのでは？って思ったが、反論に反論してきた人の中では違うらしい。確立からいうと、ほぼほぼ0に近いが。
コメント欄がかなりヒートアップしてた。
ソフトウェアの設計次第だな。
個人的には、使ってもいいと思う。
実際、個人開発で、UUIDを主キーにしてるからな。
デバックがやりにくいということも無いので、あんまり使っちゃダメっていう認識はないな。
