タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公
最近、一意な識別子について検討することがあったのでその検討メモ。 一意な識別子とは つまり、重複しない、ユニークな識別子（Identifier, 以下id）のこと。ここではRDBのテーブルにおける主キーとして使うことを想定かつ前提としている。したがって、主キーの要件であるユニーク性を持ったidをどうやって生成していくか。 そんなのDBの連番でいいじゃんて話もあるがここではその話はせず、あくまでも一意な識別子をどう生成するかの話に絞る。 選択肢 一番有名だと思われるUUIDを筆頭にいくつかの選択肢がある。 UUID ULID CUID Nano ID 他にもTwitter発のSnowflakeとか今はDeprecatedになってるshortidなどがあるが、キリがないのでここでは上記の4種類だけで簡単に比較した。また、実際にはUUIDはバージョンによってSpecが異なるがここではバージョン4
UUID（Universally Unique Identifier）と ULID（Universally Unique Lexicographically Sortable Identifier）は、両方ともユニークな識別子を生成するために使用される技術です。 UUIDにはいくつかのバージョンがあり、この記事では、UUID v4、UUID v7、およびULIDについて説明し、それらの比較を行います。 弊社GIGは、ナショナルクライアントからスタートアップまで、Webコンサルティング、UI/UXデザイン、システム開発など、DX支援をおこなうデジタルコンサルティング企業です。データベース設計やWeb制作、DX支援のご相談はいつでもご連絡ください。 ■実績紹介 ■お問い合わせはこちら UUID・ULIDとは？UUID v4UUID v4は、ランダムな値に基づいて生成される128ビットの識別子で
どうもみなさんはじめまして、2023年3月入社の id:convto です。 7月はLayerXエンジニアブログを活発にしよう月間 ということらしく、その一環で個人的に調査・検討していた内容で一本書いたろうかなということで筆を取らせていただきました。 ちょっと遅刻しちゃいましたが許してください。 モチベーション ULIDはmsec単位でsort可能な性質を持っていて、かつ多くのユースケースにとって十分な採番能力をもっているIDです。 ですが、たとえばDML実行などでSQLから生成できなくて困る場合があります。 ULIDはすこし特徴のあるencodingを使っていたりする都合でDMLでの生成が難しく、素直にやるとアプリケーション側でID生成処理を書く必要があります。なんとかならないかといろいろとやり方を検討したかたもいらっしゃるのではないでしょうか。(N敗) そこで、SQL経由でのULID生
MySQLでUUID(v4)をプライマリキーにしてはいけない理由データベースの設計でプライマリキーをどうするかは、最初に悩むところではないかと思います。特にコンシューマー向けのWebサービスやマルチテナントのB2Bサービスを開発するときなどは特に気をつかいますよね。 何も考えずにAuto increment（自動採番）型のプライマリキーを付けて、「/users/1」「/users/2」「/users/3」みたいなID付きのURLでアクセスさせてしまうと、次のような問題が生じることがあります。 URLに使われているIDの大きさや増加数から、システムの規模感や利用状況が分かってしまう。IDを機械的に変えて総当たり的に情報を取得できてしまう。また、分散したシステムでサブシステムごとに衝突しないIDを割り当てたいことがあるかもしれません。そんなときにUUIDをプライマリキーにしちゃえばいいんじゃね
エンティティの識別子の生成タイミング問題 DDD[1]では，一意な識別子を持ち，その識別子によって識別できるモデルをエンティティ (Entity) として表現します．このエンティティの識別子の生成方法には様々な種類がありますが，大きく分けて永続化前に生成する早期生成と永続化後に生成する遅延生成の2種類に分けられます． エンティティの識別子の生成に遅延生成を用いると本来 Not Null な識別子を Nullbale として扱う必要性が生じてしまいます．これを避けるのであれば，早期生成を採用すると良く，IDDD本[2]などではUUIDやGUIDをアプリケーション側で生成し識別子に用いる例が紹介されています． しかし，技術的な問題でUUIDなどのランダムな値を識別子として採用しづらいケースも存在します．たとえば，MySQL (InnoDB) ではプライマリキーにランダムな値を用いるとINSER
似て非なるもの多すぎ問題 UUIDとULIDの違い UUID（Universally Unique Identifier） ULID（Universally Unique Lexicographically Sortable Identifier） よくわからない ソートの可否（’21 6月追記） UUID ULID 一意性にかわりない 参考URL 違いシリーズ第三弾！ 第一弾と第二弾はこちら↓。（シリーズ化するつもりもない） bonoponz.hatenablog.com bonoponz.hatenablog.com 似て非なるもの多すぎ問題 いや、多いのよまじで。 故に、初心者にとって単語が理解できずに話についていけないシーン多いです。似た単語の違いを調べることがまだあるかもしれないので、先にシリーズ化を予兆する。 UUIDとULIDの違い 根本的には同じものなのかもしれない、と調べ
こんにちは、Webエンジニアのまさぴょんです！ 今回は、id を作成する際に意識した3つのチェックポイントと、文字列 id は ULID or UUID v7がおすすめという話について、解説します🐱 結論・まとめ 要点だけ、知りたい人向けに、調査結果をまとめると、次のような内容になります。 3つのチェックポイントの調査結果 id の命名は、user_idやtask_idのようにid名を具体化したが方が、明確であり可読性が上がる👀 id のデータ型は、柔軟性・拡張性が高い文字列型がおすすめ🌟 数値型の表現できる幅・フォーマットは、文字列型に比べて少ない 文字列型の方が柔軟性が高く、拡張・変更が容易 文字列の id データの生成をするなら、ULID or UUID v7がおすすめ🌟 実装難易度が低い UUID v4 はソート不能だが、ULID or UUID v7はソート可能な ID
ID（プライマリーキー）の採番方法については、主にSequential(auto increment)とUUIDv4の2つの方法があります。 UUIDはセキュリティ面などでの利点がありますが、生成が時系列順ではなくB-treeとの相性が悪いためパフォーマンスに問題があることがあります。 そのため、タイムスタンプ情報を用いて時系列順に採番できるUUIDv6、UUIDv7、UUIDv8がIETFによって提案されています。 v6はタイムスタンプがグレゴリオ暦ベース、v7はUnix Time Stampベース、v8は独自仕様ということですので、特に理由がなければv7を使うのが良さそうです。 また、同様に時系列順に採番できるものとしてULIDがオープンソースで公開されています。 今回は、Sequential、UUIDv4、UUIDv7、ULIDの4つについてPostgresSQLでパフォーマンスを測
データベースのテーブルのIDの形式は一見単純に見えますが、実際には深い洞察が求められます。 特に最近は、オートインクリメントを用いるケースが減少し、他の方法を採用する動きが見られます。 複数の項目でレコードを特定できるような場合でも、複合主キーではなく別途IDを付与することが多いです。 しかし、IDの形式には様々な選択肢が存在します。そこで、どの形式を選ぶべきかについてまとめてみました。 概論 先に簡単な結論です。 現代のWebアプリケーション開発において、基本的には「UUID v7」または「ULID」を採用することを推奨します。 これらは時系列順にソート可能であり、データベースのインデックス性能を損なわずに一意性を確保できるためです。 シャーディングを行う要件があり、IDによるデータ分散が重要な場合（例えばデータベースにTiDBを採用しているなどのケース）では、順序がランダムになるUUI
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く