UUIDとULIDを理解していない方は見た方がいい記事

Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公

[ton-boo]

auto incrementはスケールさせにくいというデメリットは押さえておきたい。UUIDv7がなかった頃の記事だけど例えばこちら https://zenn.dev/j5ik2o/articles/a085ab3e3d0f197f6559

[mingos]

Rails+PostgreSQLでプライマリキーにできるだけULIDを採用してるけど、DBに保存する時はBinaryで保存してます。ULIDは扱いやすくて便利。

[sakuro]

UUIDにせよULIDにせよ、文字列として保存することはないんじゃないか?

[rryu]

結局、UUID v7とULIDの違いは最終的なエンコードが16進文字列でなくCrockford's Base32なULIDの方が短くなるというだけの模様。

[nilab]

UUIDとULIDを理解していない方は見た方がいい記事

[mumei-0]

“ULID（Universally Unique Lexicographically Sortable Identifier）は、UUIDの欠点を補う形で設計された一意識別子です。特に、時系列順にソート可能であることが大きな特徴です。”

[gactocat]

“第三者に漏れてはいけない場合はv4を使う方が良いです。 という単純な問題でもないようです。これに関しては【#まとめのようなもの】の章で後述しております。 ULID”

[akymrk]

“数値型の自動採番に比べるとパフォーマンスは落ちます""タイムスタンプが見られるリスク”"プライマリキーには数値の自動採番を使用""ユーザーに公開するキーとしては、別途ランダムな文字列（UUIDやカスタム乱数"

[TakamoriTarou]

理解してないので読んだ。完全に理解した（やめろ　　俺の用途だとULIDがよさそうなのはわかったかも。よさげ

[toyoshi]

前職のWebサービスで過疎ってると思われたくないので会社の創立記念日をつなげた整数から連番を始めたなあ >連番のIDはデータベースの挿入順序を反映しているため〜データ生成の頻度が漏洩する可能性があります。

[tettekete37564]

DB分散するにしてもマスタ系はAutoIncrement でもで大丈夫な様に作った方が良い気もするがどうなんだろうか

[Shinwiki]

パフォーマンスに行き着くならH/Wの進化を待つってことでいいや

[attoku]

データベース

[taruhachi]

連番の主キーを隠蔽したいという目的だけなのであれば結論にはだいたい同意。

[taguch1]

毎度XIDでいいやと思ってしまう。

[Xray]

途中「完全なランダム」って言葉が使われてて、素人くせえなとは思った

[yarumato]

“ULIDは、UUIDの欠点を補う形で登場した新しい識別子で、時系列ソートが可能であることが特徴。Auto increment（自動採番）型を採用したくない理由：予測可能性、情報漏洩のリスク、スケールさせにくい”