私は過去にいくつかのデータベース システムに携わったことがありますが、データベース キーがすべてGUID / UUID値であれば、データベース間でのエントリの移動がはるかに簡単になります。この方法を取ることを何度か検討しましたが、特にパフォーマンスや電話では読み上げられない URL に関して、常に多少の不確実性があります。
データベースで GUID を広範囲に使用したことがある人はいますか? その方法を使用するとどのような利点がありますか? また、どのような落とし穴がある可能性がありますか?
ベストアンサー1
利点:
- オフラインで生成できます。
- レプリケーションが簡単になります (int の場合、レプリケーションは非常に困難になります)
- ORMは通常それらを好む
- アプリケーション間で一意です。そのため、CMS (guid) の PK をアプリ (同じく guid) で使用でき、衝突が発生することはありません。
デメリット:
- スペースの使用量は大きいが、スペースは安価である
- 挿入順序を取得するために ID で順序付けすることはできません。
- URL では見苦しいかもしれませんが、実際の DB キーを URL に入れるなんて一体どういうことでしょうか? (この点については、以下のコメントで異論があります)
- 手動でデバッグするのは難しいですが、それほど難しくはありません。
個人的には、ある程度の規模のシステムであれば、ほとんどの PK にこれを使用していますが、あらゆる場所で複製されたシステムで「トレーニング」を受けたため、これを使用する必要がありました。結果は人によって異なります。
重複データなんてナンセンスだと思います。何をやっても重複データができてしまいます。代理キーは、私が働いていたところではたいてい嫌われます。でも、私たちは WordPress のようなシステムを使っています。
- 行の一意の ID (GUID/その他)。ユーザーには表示されません。
- 公開 ID は、あるフィールド (例: タイトル - 記事のタイトルにする) から 1 回生成されます。
更新:この投稿には +1 が頻繁に付けられるので、GUID PK の大きな欠点であるクラスター化インデックスを指摘しておくべきだと思いました。
レコードが多数あり、GUID にクラスター化インデックスがある場合、挿入のパフォーマンスは低下します。これは、挿入が項目リストの最後 (高速) ではなく、ランダムな場所 (これがポイント) に行われるためです。
したがって、挿入パフォーマンスが必要な場合は、自動インクリメント INT を使用し、他のユーザーと共有する場合 (たとえば、URL でユーザーに表示する) は GUID を生成する必要があります。