私は過去に多くのデータベース システムに取り組んできましたが、すべてのデータベース キーがGUID / UUID値であれば、データベース間でエントリを移動するのはずっと簡単でした。私は何度かこの道をたどることを検討しましたが、特にパフォーマンスや電話で読み上げられない URL に関しては、常に多少の不確実性があります。
データベースで GUID を広範囲に使用したことのある人はいますか? そのようにすることで、どのような利点が得られますか? また、起こりうる落とし穴は何ですか?
98112 次
10 に答える
268
利点:
- それらをオフラインで生成できます。
- レプリケーションを自明にします (int のレプリケーションとは対照的に、レプリケーションは非常に困難になります)
- ORMは通常それらのようです
- アプリケーション間で一意。そのため、CMS (guid) の PK をアプリ (guid) で使用でき、決して衝突しないことがわかります。
短所:
- より広いスペースを使用しますが、スペースは安価です(er)
- ID で注文して挿入注文を取得することはできません。
- URL は醜く見えるかもしれませんが、実際には、URL に REAL DB キーを入れているのですか!? （この点は、以下のコメントで争われています）
- 手動でデバッグするのは難しくなりますが、それほど難しくはありません。
個人的には、まともなサイズのシステムのほとんどの PK にそれらを使用していますが、あちこちに複製されたシステムで「訓練」されたので、それらを持たなければなりませんでした。YMMV。
重複データはゴミだと思います-どのようにしても重複データを取得できます。代理キーは、私がこれまで働いてきた場所では通常、眉をひそめています。ただし、WordPress のようなシステムを使用しています。
- 行の一意の ID (GUID など)。ユーザーには表示されません。
- パブリック ID は、いくつかのフィールドから一度だけ生成されます (例: タイトル - 記事のタイトルにします)
更新: したがって、これは多くの場合 +1 されるので、GUID PK の大きな欠点であるクラスター化インデックスを指摘する必要があると考えました。
多数のレコードがあり、GUID にクラスター化されたインデックスがある場合、アイテムのリストのランダムな場所に挿入されるため (これがポイントです)、挿入のパフォーマンスは低下します (これは迅速です)。
したがって、挿入のパフォーマンスが必要な場合は、auto-inc INT を使用し、GUID を他の人と共有したい (つまり、URL でユーザーに表示する) 場合は、GUID を生成します。
于 2008-09-05T09:44:55.717 に答える
15
なぜ誰もパフォーマンスについて言及しないのですか？複数の参加がある場合、すべてこれらの厄介なGUIDに基づいて、パフォーマンスがフロアを通過します:(
于 2008-09-06T01:05:27.687 に答える
14
主な利点は、データベースに接続せずに一意の ID を作成できることです。また、ID はグローバルに一意であるため、異なるデータベースのデータを簡単に組み合わせることができます。これらは小さな利点のように思えますが、過去に多くの作業を節約してきました。
主な欠点は、もう少し多くのストレージが必要であること (最新のシステムでは問題ではありません) と、ID が実際には人間が判読できないことです。これは、デバッグ時に問題になる可能性があります。
インデックスの断片化など、パフォーマンスの問題がいくつかあります。しかし、それらは簡単に解決できます (jimmy nillson による櫛ガイド: http://www.informit.com/articles/article.aspx?p=25862 )
編集は、この質問に対する私の2つの回答をマージしました
@Matt Sheppard 彼は、主キーとして異なる GUID を持つ行を複製できることを意味していると思います。これは、GUID だけでなく、あらゆる種類の代理キーの問題です。そして、彼が言ったように、意味のある一意の制約を非キー列に追加することで簡単に解決できます。別の方法は自然キーを使用することであり、それらには実際の問題があります..
于 2008-09-05T08:15:35.713 に答える
14
@マットシェパード：
顧客のテーブルがあるとします。確かに、顧客がテーブルに複数存在することは望ましくありません。そうしないと、販売部門と物流部門全体で多くの混乱が発生します (特に、顧客に関する複数の行に異なる情報が含まれている場合)。
したがって、顧客を一意に識別する顧客識別子があり、顧客と顧客サービス担当者が通信する必要がある場合に備えて、その識別子が (請求書で) 顧客に知られていることを確認します。顧客レコードが重複しないことを保証するには、顧客 ID の主キーまたは顧客 ID 列の NOT NULL + UNIQUE 制約を使用して、一意性制約をテーブルに追加します。
次に、何らかの理由 (私には思いつきません) で、顧客テーブルに GUID 列を追加し、それを主キーにするよう求められます。GUID が常に一意であるため、顧客 ID 列が一意性の保証なしで残されている場合、組織全体で将来の問題が発生する可能性があります。
一部の「アーキテクト」は、「ああ、しかし、実際の顧客の一意性制約はアプリ層で処理しています!」と言うかもしれません。右。その汎用プログラミング言語と (特に) 中間層フレームワークに関するファッションは常に変化しており、通常、データベースが存続することはありません。また、ある時点で、現在のアプリケーションを介さずにデータベースにアクセスする必要が生じる可能性が非常に高くなります。==トラブル。(しかし、幸いなことに、あなたと「アーキテクト」は長い間いなくなっているので、混乱を一掃するためにそこにいることはありません。) 言い換えれば、データベース内 (および他の層でも同様に、明らかな制約を維持してください。時間）。
言い換えれば、テーブルに GUID 列を追加する正当な理由があるかもしれませんが、実際の(==非 GUID) 情報内での一貫性に対する野心を下げる誘惑に陥らないでください。
于 2008-09-05T09:28:10.903 に答える
11
GUID が "uniqifiers" として使用され、重複したデータがテーブルに取り込まれると、将来、多くの問題が発生する可能性があります。GUID を使用する場合は、他の列で UNIQUE 制約を引き続き維持することを検討してください。
于 2008-09-05T08:38:43.770 に答える
8
その列をクラスター化インデックスとしても使用している場合に、GUIDSを主キーとして使用する際に考慮すべきもう1つの小さな問題（比較的一般的な方法）。GUIDの性質上、挿入はヒットしません。これは、GUIDがシーケンシャルで開始されないため、挿入時にページ分割などになります。システムのIOが高くなるかどうかを検討するだけです...
于 2008-09-16T02:40:09.823 に答える
8
主キーとしての GUID のコスト(SQL Server 2000)
神話、GUID と自動インクリメント(MySQL 5)
これは本当にあなたが望むものです。
UUIDの長所
- すべてのテーブル、すべてのデータベース、すべてのサーバーで一意
- 異なるデータベースからのレコードを簡単にマージできます
- 複数のサーバーにデータベースを簡単に分散できます
- データベースへのラウンドトリップの代わりに、どこでも ID を生成できます。
- とにかく、ほとんどのレプリケーション シナリオには GUID 列が必要です
GUID 短所
- これは、従来の 4 バイトのインデックス値よりも 4 倍も大きくなります。注意しないと、これはパフォーマンスとストレージに深刻な影響を与える可能性があります
- デバッグが面倒 (userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
- 生成された GUID は、最高のパフォーマンス (SQL 2005 の newsequentialid() など) とクラスター化インデックスの使用を可能にするために、部分的に連続している必要があります。
于 2013-10-26T08:13:02.150 に答える
1
利点:
- UUID 値は、テーブルとデータベースの間で一意です。そのため、2 つのデータベース間または分散データベース間で行をマージすることができます。
- UUID は、整数型のデータよりも URL を通過する方が安全です。URL を介して UUID を渡すと、攻撃者は次の ID を推測できません。しかし、10 などの整数型を渡すと、攻撃者は次の ID が 11、12 などであると推測できます。
- UUID はオフラインで生成できます。
于 2020-07-27T19:31:08.557 に答える