ユーザーID

ユーザーIDを作成する場合、連番で採番されるIDを採用すると1つ数字を間違えただけで他のユーザーへ処理が適用されてしまうというデメリットがあります。

例

ID	ユーザー名	削除フラグ
4351	テスト	0
4352	ミーグラム	0
435	ミミューズ	0

4351の「テスト」を削除しようとして間違えて435や4352と入力してしまった場合に他のユーザーを削除するケースなどが想定されます。

システムで利用するのみであれば問題ないのですが、手動での対応が発生する場合はミスが発生しやすいです。ミーグラムではお問合せの対応で手動対応が発生するケースも多いため、連番でないIDを導入する必要がありました。

ユニークなIDについては事前にUUIDに関する知識があったため、UUIDを採用しようと考えましたが、導入するサービスの仕様で25文字以内の文字列しか利用できないという制限があり断念しました。UUIDはv4が主流ですが、36文字と25文字をオーバーしてしまっていました。

UUIDv4の例

f47ac10b-58cc-4372-a567-0e02b2c3d479

その他にULIDというのも出てきましたが、26文字ということでこちらも採用できませんでした。

ULIDの例

01HFW6EZ1VGKS5TN9A4Z6F0P7X

そこで利用することに決めたのが、PHPの関数であるuniqid()です。最小で13文字から利用できるため、文字数制限の要件を満たしていました。ランダムな文字列を付与するオプションを利用しても25文字以内に収まったため、利用しました。

uniqid('', true);

UUIDのv4と比較すると時間ベースでIDが作成されることで作成時間が分かってしまうことや「.」が付くことなどの懸念点もありましたが、ユーザー側に表示するIDではないためそこまで気にする必要はないと考えました。また、UUIDと比較するとランダム性が低いという懸念もありましたが、こちらも現在及び当分の間のサービスのユーザー数を考慮すると十分であると考えました。

サブスクリプションID

こちらもお問合せ対応などで手動利用するため、高いユニーク性が必要でした。

UUIDv4を考えましたが、ユーザー側に表示する際、36桁というのはやはり長く改行が入ってしまうため、選定しませんでした。

ユーザーIDの時に考慮したULIDを採用しました。UUIDv4と比較し、26桁と少ないことや時間ベースで作成されるため、ソートや検索において高いパフォーマンスであることが選定理由です。

use Ulid\Ulid;

subscriptionId = Ulid::generate(true);

Laravelの最新バーションであれば関数が用意されているようですが、利用しているバージョンでは利用できなかったため、以下のライブライを利用しました。

ULIDは時間が分かってしまうという懸念点がありましたが、他のユーザーに表示されるIDではないためそこまで厳密に考慮する必要は

実際に選定してみて

最初はUUIDv4を使えば良いのかなと考えていましたが、見た目やパフォーマンス的にもULIDいいなと思いました。また、相当大きいサービスのIDや他のサービスも含めてランダム性が求められる項目でなければ、ランダム性をそこまで求める必要もないと感じました。