[解決済み】GUID / UUIDデータベースキーの利点と欠点

質問

私は過去にいくつかのデータベースシステムで作業したことがありますが、もしデータベースのキーがすべて GUID / UUID の値です。何度かこの道を歩もうと考えたことがありますが、特にパフォーマンスや電話では読めないURLなど、常にちょっとした不安がつきまといます。

データベースでGUIDを広範囲に扱ったことのある方はいらっしゃいますか？また、そのような方法でどのような利点があり、どのような落とし穴がありそうですか？

どのように解決するのですか？

メリット

• オフラインで生成できる
• レプリケーションが簡単になる(int型は非常に難しい)
• ORMに好かれる
• アプリケーション間で一意であること。だから、CMSのPK(guid)をアプリ(guid)で使えば、絶対に衝突しないことがわかる。

デメリット

• 使用するスペースが大きくなるが、スペースが安い（笑）
• 挿入順をIDで注文できない。
• URLで醜く見えることがありますが、本当に、URLでリアルなDBのキーを入れているのはWTFですか！？(この点については、以下のコメントで議論されています。）
• 手動デバッグがしにくいが、それほど難しくはない。

個人的には、それなりの規模のシステムであれば、ほとんどのPKに使っていますが、あちこちで複製されているシステムで"trained"を受けたので、どうしても必要だったのです。YMMV。

重複データというのはくだらないと思います。どうやったって重複データはできてしまうのですから。サロゲートキーは、私がこれまで働いてきたところではたいてい嫌われます。しかし、私たちはWordPressのようなシステムを使用しています。

• 行の一意のID（GUID/何でも）。ユーザーには決して見えません。
• 公開IDは、何らかのフィールドから一度だけ生成される（例：タイトル - the-title-of-the-articleとする）。

UPDATEです。 これはよく+1されるのですが、GUID PKの大きな欠点を指摘しておこうと思ったのです。クラスター化インデックス

多くのレコードがあり、GUIDにクラスタ化されたインデックスがある場合、挿入パフォーマンスは最悪です。

したがって、挿入パフォーマンスが必要な場合は、自動インクINTを使用し、誰かと共有したい場合はGUIDを生成するとよいでしょう（たとえば、URLでユーザーにそれを表示する）。