79

シンプルさと（想定される）速度のために、データベースの主キーとして長整数を使用することを常に好んでいました。しかし、オブジェクト インスタンスにRESTまたは Rails のような URL スキームを使用すると、次のような URL になります。

http://example.com/user/783

次に、782、781、...、2、および 1 の ID を持つユーザーも存在すると仮定します。問題の Web アプリが、他のユーザーを許可なく表示するために他の番号を入力することを防ぐのに十分安全であると仮定すると、単純な連続して割り当てられた代理キーも、インスタンスの総数 (これよりも古い) を「漏えい」します。この場合はユーザーであり、これは特権情報である可能性があります。(たとえば、私はスタックオーバーフローのユーザー #726 です。)

UUID /GUID はより良い解決策でしょうか? 次に、次のような URL を設定できます。

http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66

正確には簡潔ではありませんが、表示されるユーザーに関する暗黙の情報は少なくなります。確かに、適切なセキュリティに代わるものではない「あいまいさによるセキュリティ」の匂いがしますが、少なくとももう少し安全に見えます.

その利点は、Web アドレス可能なオブジェクト インスタンスに UUID を実装するコストと複雑さに見合う価値があるでしょうか? 結合を高速化するためだけに、整数列をデータベース PK として使用したいと思います。

UUID のデータベース内表現の問題もあります。MySQL がそれらを 36 文字の文字列として保存することは知っています。Postgres はより効率的な内部表現 (128 ビット?) を持っているようですが、私自身は試していません。誰でもこれを経験したことがありますか？

更新: URL (例: http://example.com/user/yukondude )でユーザー名のみを使用することについて尋ねた人のために、一意の名前を持つオブジェクト インスタンスに対しては問題なく機能しますが、無数の Web についてはどうでしょうか。本当に番号でしか識別できないアプリオブジェクト? 注文、取引、請求書、画像名の重複、stackoverflow の質問、...

4

15 に答える 15

34

あなたの質問のウェブ側については言えません。ただし、uuid は n 層アプリケーションに最適です。PK の生成は分散化できます。各クライアントは、衝突のリスクなしに独自の PK を生成します。そして、速度差は一般的に小さいです。

データベースが効率的なストレージ データ型 (16 バイト、128 ビット) をサポートしていることを確認してください。少なくとも、uuid 文字列を base64 でエンコードし、char(22) を使用できます。

私は Firebird でそれらを広く使用しており、お勧めします。

于 2008-08-08T14:03:00.833 に答える
29

価値があるのは、GUID プライマリ キーから整数に切り替えるだけで、長時間実行されるストアド プロシージャ (9 秒以上) の実行時間がわずか数百ミリ秒に短縮されることです。GUID を表示することが悪い考えだと言っているわけではありませんが、他の人が指摘しているように、それらに結合してインデックスを作成することは、定義上、整数の場合ほど速くはありません。

于 2008-08-08T15:20:35.857 に答える
23

SQL サーバーで、uniqueidentifier (GUID) データ型を使用し、NEWID() 関数を使用して値を作成すると、ページ分割のためにひどい断片化が発生するということをお答えできます。その理由は、NEWID() を使用すると、生成される値が連続していないためです。SQL 2005 では、これを修正するために NEWSEQUANTIAL() 関数が追加されました。

GUID と int を引き続き使用する 1 つの方法は、guid と int をテーブルに配置して、guid が int にマップされるようにすることです。GUID は外部で使用されますが、int は DB の内部で使用されます

例えば

457180FB-C2EA-48DF-8BEF-458573DA1C10    1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A    2

1 と 2 は、Web アプリの結合と GUID で使用されます。このテーブルはかなり狭く、クエリはかなり高速になるはずです

于 2008-08-08T14:05:56.630 に答える
10

主キーを URI と結合するのはなぜですか?

URI キーを人間が読める (または必要に応じて推測できない) ものにし、プライマリ インデックスを整数ベースにすることで、両方の世界を最大限に活用できます。多くのブログ ソフトウェアはこれを行っており、公開されたエントリの ID は「スラッグ」によって識別され、数値 ID はシステム内に隠されています。

ここでの追加の利点は、SEO に適した非常に優れた URL 構造が得られることです。明らかに、トランザクションの場合、これは良いことではありませんが、stackoverflow のようなものでは重要です (上の URL を参照してください...)。一意性を取得することはそれほど難しくありません。本当に心配な場合は、スラッグのハッシュをテーブル内のどこかに保存し、挿入する前にルックアップを行ってください。

編集: Stackoverflow は、私が説明するシステムをまったく使用していません。以下の Guy のコメントを参照してください。

于 2008-09-16T05:24:56.510 に答える
4

行番号に関連しているが連続していない整数を使用できます。たとえば、シーケンシャル ID の 32 ビットを取得して、固定スキームで並べ替えることができます (たとえば、ビット 1 はビット 6 になり、ビット 2 はビット 15 になります)。
これは双方向の暗号化であり、2 つの異なる ID には常に異なる暗号化が適用されます。
十分なIDを生成してスキーマを取得するのに時間がかかる場合は、明らかに簡単にデコードできますが、問題を正しく理解していれば、簡単に情報を提供したくないだけです。

于 2008-08-12T18:20:16.023 に答える
4

次のような URL ではなく:

http://example.com/user/783

持っていない理由:

http://example.com/user/yukondude

どちらが人間にやさしく、わずかな情報を漏らさないでしょうか?

于 2008-08-08T18:24:15.797 に答える
4

GUID は、MS SQL Server レプリケーションの RowGUID としても機能するため、すべてのテーブルの主キーとして使用します。クライアントが突然世界の別の場所にオフィスを開設したときに、非常に簡単になります...

于 2008-08-12T21:00:12.877 に答える
3

GUID が多くの利点をもたらすとは思いません。ユーザーは、長くてわかりにくい URL を嫌います。

URL にマップできる短い ID を作成するか、一意のユーザー名規則 ( http://example.com/user/brianly ) を適用します。37Signals の担当者は、Web アプリに関してこのようなことを心配していると、おそらくあなたをからかうでしょう。

ちなみに、ベース値から整数 ID の作成をデータベースに強制的に開始させることができます。

于 2008-08-08T15:10:04.240 に答える
3

また、アプリケーションの何を重視するかによっても異なります。n 層アプリの場合、GUID/UUID は実装が簡単で、異なるデータベース間での移植も簡単です。整数キーを生成するために、シーケンス オブジェクトをネイティブにサポートするデータベースもあれば、シーケンス テーブルのカスタム構築を必要とするデータベースもあります。

整数キーはおそらく (私は数字を持っていません)、クエリとインデックス作成のパフォーマンスだけでなく、スペースの使用にも利点をもたらします。ダイレクト DB クエリも、数値キーを使用するとはるかに簡単になり、覚えやすいため、コピー/貼り付けが少なくなります。

于 2008-09-16T00:31:55.903 に答える
2

私は、UUID を整数の形で使用する学生管理システムを使用しています。次の一意の ID を保持するテーブルがあります。

これはおそらくアーキテクチャの観点からは良い考えですが、日常的に作業するのは困難です。一括挿入を行う必要がある場合があり、UUID があるとこれが非常に難しくなり、通常は単純な SELECT INTO ステートメントの代わりにカーソルを記述する必要があります。

于 2008-08-08T13:59:46.673 に答える
2

実際の Web アプリで両方を試しました。

私の意見では、整数を使用し、短くてわかりやすい URL を使用することをお勧めします。

開発者として、連続する整数を見て、総レコード数に関する情報が漏洩していることを知るのは少し気が重くなりますが、正直なところ、ほとんどの人はおそらく気にしないでしょうし、その情報は私のビジネスにとって本当に重要ではありません.

長い醜い UUID URL を持つことは、通常のユーザーにとってははるかに嫌なことのように思えます。

于 2013-10-02T03:43:39.030 に答える
1

あなたの状況では、GUIDを使用する方が良い選択だと思います。より多くのスペースを占有しますが、より安全です。

于 2008-08-08T14:00:49.323 に答える
1

これは、準宗教的な議論を引き起こす問題の 1 つであり、話すことはほとんど無益だと思います。好みのものを使用してください。システムの 99% では、使用するキーの種類は問題にならないため、ある種類のキーを使用する利点 (他の投稿で述べられています) が問題になることはありません。

于 2008-08-12T19:30:13.137 に答える
-1

ストレージ効率の良いDBシステムを使えば、最近はとにかくHDDが安い…。

GUID がうまく動作しない場合があり、クエリのオーバーヘッドが発生することはわかっていますが、セキュリティの観点からは、GUID は救世主です。

あいまいなURIを形成し、テーブル、レコード、および列で定義されたセキュリティを使用して正規化されたDBを構築するときに、あいまいさによるセキュリティを考えると、GUIDで問題が発生することはありません。整数ベースのIDでそれを試してください。

于 2013-02-25T10:41:35.423 に答える