Identityの設計

IDの振り方

発行速度

枯渇

推測可能性

連番はだいたいやばい

自明にequalityがあるimmutableで小さいデータはIDを必要としない

IDを振るのは、ミュータブル(仕様の不確定性による未来の変化が主)なデータに対して人為的な一定性を導入したい場合

同一性

比較可能性

hash値についての考え方

hashがまだないがIDはほしいケースを別ID空間で処理できるか? / そうじゃないならhashをIDとして使うべきではない

e.g. blob uploaderのupload中

パターン1: upload_request_id, blob_id(hash)

パターン2: blob_id(not hash)

衝突したら... / hashの安全性が損なわれたら...

hash使わないほうが無難

一方で、data identifierとしてhashを使うことで圧倒的簡略ができるシステムもある

e.g. git, bazel, bitcoin

identity定義が変わる場合

変わる余地を残すべき場合、そうじゃない場合

変えたい場合: "ID"が特定実装に紐づいている / 不確定な製品上の概念を指している

変えたくない場合:

どう帰ることを防ぐか

どう変えるか

防いでたのに変えたくなった場合

Best Practice

いつでも、文字セット・アドレス空間を限定する & 厳密に定義しておく

自然に見える制約だけど、空きがあって、空きを入れてもそこそこ自然に見える

後で拡張したくなったときの対策

IDとトークンの区別

equalityを使うトークン: ID