サクサク読めて、アプリ限定の機能も多数！アプリで開くはてなブックマーク閉じる ●はてなブックマークって？●アプリ・拡張の紹介●ユーザー登録●

●ログアウト

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

テクノロジーカテゴリーの変更を依頼記事元:

jp.quora.com

737 usersがブックマークコメント

78

現在プライベートモードです設定を変更する

737 users jp.quora.com

現在プライベートモードです設定を変更する

みんなの興味と感想が集まることで新しい発見や、深堀りがもっと楽しくアカウントをお持ちの方はログインページへ

記事へのコメント78件

●注目コメント ●新着コメント

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

zentarou バージョンなしでUUIDを語るのは微妙 2024/05/16 リンクその他 ● ● ●

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

otchy210 それだけを問題にするなら UUIDv4 じゃなくて UUIDv6 を使えば良いのでは？と思う。むろんそれだけではないのだが。 2024/05/15 リンクその他 ● ● ●

hirata_yasuyuki id:gowithyou ﹁容易にIdを推測されないため﹂その話、対策含めて最初の方に出てくるよ。 2024/05/16 リンクその他 ● ● ●

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

Windymelt 内容はもっともと思うけどなんでこうわざわざチクチク書くんだろう > "そもそも分散システムを設計するための基本的なスキルが不足していると言わざるをえません。" ●tech-技術 ●db 2024/05/16 リンクその他 ● ● ●

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

gi2357 この辺のデータの局所性の話、今0からやるならdynamoDBの設計やったほうが身につくかも 2024/05/16 リンクその他 ● ● ●

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

soulfulmiddleagedman uuidv7 2024/06/21 リンクその他 ● ● ●

cpw idをプログラム側で採番できるというデカいメリットがあるよ。でもそれが必須となることはほぼ無い。 ●データベース 2024/05/17 リンクその他 ● ● ●

Soujyu “UUID” 2024/05/16 リンクその他 ● ● ●

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

andvert おもろー！！！！ 2024/05/16 リンクその他 ● ● ●

devrabi ばらけさせたいのか、順序性を持たせたいのか 2024/05/16 リンクその他 ● ● ●

akymrk “乱数は﹁参照の局所性﹂︵Locality of Reference︶というコンピューターサイエンス最強の武器を殺してしまう”"データ圧縮のアルゴリズムも、データの﹁偏り﹂を利用します。完全にランダムなデータは圧縮しても縮みませ" 2024/05/16 リンクその他 ● ● ●

kojikanet ULIDで問題が全て解決するだと思うけど、なんで言及してないんだろう。 2024/05/16 リンクその他 ● ● ●

paradoxparanoic idを時系列として取ってくる事はないからなあ。uuidにしようとも思わないけど 2024/05/16 リンクその他 ● ● ●

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

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

Windymelt 内容はもっともと思うけどなんでこうわざわざチクチク書くんだろう > "そもそも分散システムを設計するための基本的なスキルが不足していると言わざるをえません。" ●tech-技術 ●db 2024/05/16 リンクその他 ● ● ●

natu3kan UUIDでもバージョンによっては時間でソートできるし、設計と目的次第な所はあるか。 ●database 2024/05/16 リンクその他 ● ● ●

sakuro UUIDv4限定のお話 2024/05/16 リンクその他 ● ● ●

yoiIT “﹁たまたま次の検索でキャッシュヒットする確率は10%﹂になります。連番だった場合にはキャッシュヒット率は99%以上” 2024/05/16 リンクその他 ● ● ●

mk173 完全なランダムはキャッシュや圧縮に不利なのか 2024/05/16 リンクその他 ● ● ●

prograti 代理IDにはUUIDではなくてStripeのObject IDのようなものが好みかも https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a 2024/05/16 リンクその他 ● ● ●

yoshi-na ブコメも参考にする 2024/05/16 リンクその他 ● ● ●

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

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

hoge_hoge_123 v4だけがuuidじゃないよ 2024/05/16 リンクその他 ● ● ●

zakinco 何を作りたいかによるよね 2024/05/16 リンクその他 ● ● ●

knitcapmann 何をやりたいシステムなのかによる。開発者の論理だけでは判断できない。 2024/05/16 リンクその他 ● ● ●

hachiking UUIDv6-8のようni 2024/05/16 リンクその他 ● ● ●

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

kirarapoo Spannerのような分散型DBだとホットスポットが発生するアンチパターンになるので注意が必要なやつ 2024/05/16 リンクその他 ● ● ●

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

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

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

stamprally なるほどねぇ 2024/05/16 リンクその他 ● ● ● 注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の﹁建設的コメント順位付けモデルAPI﹂を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

<iframe marginwidth="0" marginheight="0" src="https://b.hatena.ne.jp/entry.parts?url=https%3A%2F%2Fjp.quora.com%2F%25E3%2583%2587%25E3%2583%25BC%25E3%2582%25BF%25E3%2583%2599%25E3%2583%25BC%25E3%2582%25B9%25E3%2581%25A7%25E3%2583%25A6%25E3%2583%258B%25E3%2583%25BC%25E3%2582%25AF%25E3%2582%25AD%25E3%2583%25BC%25E3%2581%25ABUUID%25E3%2582%2592%25E4%25BD%25BF%25E3%2581%2586%25E3%2583%25A1%25E3%2583%25AA%25E3%2583%2583%25E3%2583%2588%25E3%2581%25AF%25E4%25BD%2595" scrolling="no" frameborder="0" height="230" width="500"><div class="hatena-bookmark-detail-info"><a href="https://akarinohon.com/text/taketori.cgi/https://jp.quora.com/%25E3%2583%2587%25E3%2583%25BC%25E3%2582%25BF%25E3%2583%2599%25E3%2583%25BC%25E3%2582%25B9%25E3%2581%25A7%25E3%2583%25A6%25E3%2583%258B%25E3%2583%25BC%25E3%2582%25AF%25E3%2582%25AD%25E3%2583%25BC%25E3%2581%25ABUUID%25E3%2582%2592%25E4%25BD%25BF%25E3%2581%2586%25E3%2583%25A1%25E3%2583%25AA%25E3%2583%2583%25E3%2583%2588%25E3%2581%25AF%25E4%25BD%2595">データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。</a><a href="https://akarinohon.com/text/taketori.cgi/https://b.hatena.ne.jp/entry/s/jp.quora.com/%25E3%2583%2587%25E3%2583%25BC%25E3%2582%25BF%25E3%2583%2599%25E3%2583%25BC%25E3%2582%25B9%25E3%2581%25A7%25E3%2583%25A6%25E3%2583%258B%25E3%2583%25BC%25E3%2582%25AF%25E3%2582%25AD%25E3%2583%25BC%25E3%2581%25ABUUID%25E3%2582%2592%25E4%25BD%25BF%25E3%2581%2586%25E3%2583%25A1%25E3%2583%25AA%25E3%2583%2583%25E3%2583%2588%25E3%2581%25AF%25E4%25BD%2595">はてなブックマーク - データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。</a></div></iframe>

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！ ●バナー広告なし ●ミュート機能あり ●ダークモード搭載アプリをダウンロード

usersに達しました！

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