データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。

回答 (7件中の1件目) まずはUUID及びその対案として用いられる連番(自動採番)のメリット・デメリットを整理します。 (タイムスタンプキーや複合キーなどもその効率性から設計上有用なシーンはありますが、比較から除外します。) * UUIDを使うことのメリット * * データベースにSQLを送信する前からアプリケーションレイヤーでIDを生成できる。 * * トランザクション処理を実装しやすい場合がある。 * IDを推測しにくい。リソースが列挙可能ではない。 * UUIDを使うことのデメリット * * レコード・インデックスサイズが増加する。 * * ...

[w1234567]

マジメに読んでないけど先頭にタイムスタンプを保持するUUID v7は割とアリな気がしてる、まあ外部で生成されたデータであってもテーブルのPKは整数IDでUUIDはAKで持たせてシステム内では整数IDで統一しろは同意

[zentarou]

バージョンなしでUUIDを語るのは微妙

[taruhachi]

将来的に分散DBになる必然があるかの先行投資だと思ってる。テスト時やダミーデータ生成時などのコストは上がるし、実際に分散DBが必須になることは殆どないという感覚。

[otchy210]

それだけを問題にするなら UUIDv4 じゃなくて UUIDv6 を使えば良いのでは？と思う。むろんそれだけではないのだが。

[hirata_yasuyuki]

id:gowithyou 「容易にIdを推測されないため」その話、対策含めて最初の方に出てくるよ。

[turanukimaru]

この説明は正しいんだけどUUIDの「真面目な」記事はだいたい分散DBの話をしてるのでそこはくんであげて欲しい。私としては例えばゲームのアイテムに雑にIDを振るときとかはUUIDのが軽いと思う。人との紐づけは人のIDだし

[Windymelt]

内容はもっともと思うけどなんでこうわざわざチクチク書くんだろう > "そもそも分散システムを設計するための基本的なスキルが不足していると言わざるをえません。"

[gowithyou]

容易にIdを推測されないためだよ。連番だと値をインクリメントすることによってブルートフォースアタックを仕掛けられやすいだろ

[gi2357]

この辺のデータの局所性の話、今0からやるならdynamoDBの設計やったほうが身につくかも

[yojik]

今となっては諸問題が解決されているULIDでいいじゃんとなっている (シーケンスはデータ移行時に面倒、データ保存前に一意IDを振りたいときに無力なので)

[cpw]

idをプログラム側で採番できるというデカいメリットがあるよ。でもそれが必須となることはほぼ無い。

[Soujyu]

“UUID”

[R2M]

採番をDBに依存したくないとか局所性はあまり重要じゃないとか、更新におけるページロックへの対策とかまぁ色々あるよね

[andvert]

おもろー！！！！

[devrabi]

ばらけさせたいのか、順序性を持たせたいのか

[akymrk]

“乱数は「参照の局所性」（Locality of Reference）というコンピューターサイエンス最強の武器を殺してしまう”"データ圧縮のアルゴリズムも、データの「偏り」を利用します。完全にランダムなデータは圧縮しても縮みませ"

[kojikanet]

ULIDで問題が全て解決するだと思うけど、なんで言及してないんだろう。

[paradoxparanoic]

idを時系列として取ってくる事はないからなあ。uuidにしようとも思わないけど

[n314]

そんな難しい話なのかな？分散システムでキーも分散して生成したいっていう要求がまず始めにあったから、UUIDなら可能っていう流れじゃないのかな。その歴史を知らないと意味不明に見えるっていう。

[daichirata]

サイズ的にもページキャッシュにのる量とかwriteback周りとか問題は他にも色々あるけどミドルウェアの実装依存の話ではあるのでデータベースという主語で区切っちゃうのが正しいのかというのはちょっとある。

[natu3kan]

UUIDでもバージョンによっては時間でソートできるし、設計と目的次第な所はあるか。

[sakuro]

UUIDv4限定のお話

[yoiIT]

“「たまたま次の検索でキャッシュヒットする確率は10%」になります。連番だった場合にはキャッシュヒット率は99%以上”

[mk173]

完全なランダムはキャッシュや圧縮に不利なのか

[prograti]

代理IDにはUUIDではなくてStripeのObject IDのようなものが好みかも https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a

[yoshi-na]

ブコメも参考にする

[nilab]

「プライマリキーをUUIDにする莫大なコストには全く見合わないので、プライマリキーは連番のままにしておき、public_idという別カラムを用意してそこに乱数ベースのデータを入れてユニーク制約をかけておきます」

[naggg]

"結論から言うと、プライマリキーには原則としてデータベース側で発行される自動インクリメントの連番を使っておくのが間違いない、と覚えておいてください。"

[hoge_hoge_123]

v4だけがuuidじゃないよ

[zakinco]

何を作りたいかによるよね

[knitcapmann]

何をやりたいシステムなのかによる。開発者の論理だけでは判断できない。

[hachiking]

UUIDv6-8のようni

[hnw]

参照局所性よりもインデックスのサイズが大きくなる方が影響が大きいと思うけどな。自動インクリメントなら64bit整数で済むところをUUIDの文字列表現で格納してる現場もありそう。

[kirarapoo]

Spannerのような分散型DBだとホットスポットが発生するアンチパターンになるので注意が必要なやつ

[lyiase]

このUUID(恐らくv4)最大の利点は「事前確認なしで衝突安全性を確保できる」点と、「お互いのIDの間が非常に疎」なこと。トップ回答が正しいんだけど、それはUUIDv3/v4/v5の話で、UUIDv1/v6/v7/v8では当てはまらないんだよな

[queeuq]

最初の回答の1の用途が大半だろう。そして今採用するならuuidv7やULIDのようなタイムスタンプが頭に付いてるやつだし問題なさそうな/昔はS3はUUIDのようにしないとパフォーマンス悪いとかあったなぁと思いを馳せる

[Flume]

大して規模も大きくなくてセキュリティもそこそこで良い案件とかにも、なんとなく流行ってるからって理由でUUID使ってたりすると結構ゲンナリするね。

[stamprally]

なるほどねぇ

[toro-chan]

前提として表を想定するか、分散データ(表でない 順番バラバラのデータ)を想定するかによって違うと思う。表なら連番IDの方が良い。分散データはUUIDの方が良い。