はじめに
オリジナルアプリを作成するにあたって、Supabaseを使用してデータベースを構築しました。その際に、各テーブルのIDカラムの型を指定する際に新しく学んだことがあったため、備忘録も兼ねてまとめていきます。
調べるきっかけになったこと
データベース設計を行う際に、各テーブルに主キーを設定すると思います。
その際、私は以下のようにInteger型を指定していました。
| カラム名 | 型 | |
|---|---|---|
| PK | id | Integer |
| nickname | String | |
| String | ||
| password | String |
今までMySQLを使ってデータベース構築をすることが多く、主キーに対して自動インクリメント(ID)でidフィールドを設定していたのですが...
Supabaseの場合だとUUIDで保存されるので、idカラムはString型にしましょう
とレビューをいただいたので、自動インクリメント型(Integer型)とUUID(String型)で主キーを保存する違いについて調べてみました。
自動インクリメント型(Integer)
IDが連番の整数値で管理される。
データベースのIDフィールドに新しいレコードが追加されるたびに、1,2,3...と順番にID番号が増加する。
特徴
- 一意性
1つのデータベース内で一意のIDを持つ。
ただし、異なるデータベースやシステムの間では重複する可能性がある。
- メモリ効率がよい
32ビットまたは64ビットの整数型で、最大でも10桁や19桁の数値で表されるため、インデックスや検索を効率的に行うことができる。
- 管理がシンプルだが、特定がしやすい
数値で管理をするので、視覚的に分かりやすくデータ管理ができる。
一方で、連番でデータを管理するため次のIDが予測しやすく、セキュリティリスクがある。
UUID
全世界で一意の識別子を生成するための方法。
現在多くのRDSで採用されており、どのIDとも重複しないのでユニーク性の高さが保証されている。
- 一意性
世界中で一意のIDを生成できる。
異なるシステム間やデータベース間でUUIDが衝突する可能性が極めて低い。
- サイズが大きい
128ビットのデータを使って生成されるため、一般的に36文字で表現される。
そのためかなり長い文字列になり、インデックスや検索性能に影響を与える場合がある。
- 推測されにくい
ランダムに生成されるため、外部からIDを推測することが非常に困難。
人間が読みやすい形式ではないため、視認性は落ちるがセキュリティの安全性は高い。
両者の比較
| 特徴 | 自動インクリメント | UUID |
|---|---|---|
| 一意性 | データベースの中のみ一意 | 全世界で一意 |
| サイズ | 32bitまたは64bit | 128bit |
| 推測性 | 高い | 低い |
| 用途 | 小規模システム, パフォーマンス重視 | 分散システム,セキュリティ重視のシステム |
| パフォーマンス | 高速かつ効率的 | インデックス効率が低いことがある |
| セキュリティ | 低い | 高い |
| データベースサイズ | 小さい | 大きい |
使い分けは？
システムの要件や規模、用途によって選択をする必要があるが、以下をベースに判断する。
- 小規模、シンプルな構成のアプリケーション→自動インクリメント(Integer型)
- 分散システムや高いセキュリティを求める場合→UUID