aspnet_users が int をインクリメントするのではなく、id に guid を使用するのはなぜですか?
また、これを他のテーブルで主キーとして使用しない理由はありますか? 過去に使用したほとんどのアプリが通常の int システムを使用していることを知っているので、少し奇妙に感じます。
また、この ID を使用して、追加のユーザー設定などの拡張詳細テーブルと照合しようとしています。GUID と int を含むリンク テーブルを使用することも検討していましたが、そうは思わないので、それを決定しました。実際には、ユーザー ID を public int として持つ必要があります。
私は int を持ちたいと思っていますが (ユーザールックアップなどを行う方が簡単だと感じます stackoverflow.com/users/12345/user-name ) 、ユーザー名を取得するだけなので、これを運ぶ必要はないと思いますユーザーの int を検索する必要がある場合は、ルックアップがさらに複雑になります。
これについて何か助けてくれてありがとう。
主キーとしての GUID は、基礎となるデータベースをあまり気にしない (気にしたくない、または気にしない) 特定のプログラマー グループに非常に人気があります。
GUID は一意であることが (ほぼ) 保証されており、クライアント アプリで .NET コードで "事前に" 作成できるため、優れています。
残念ながら、それらの人々は、SQL Server に関しては、これらの選択肢の恐ろしいマイナス面 (恐ろしいインデックスの断片化とそれによるパフォーマンスの低下) を認識していません。多くのプログラマーは本当に少しでも気にしません.....そして、SQL Server が犬のように遅いと非難します。
主キーに GUID を使用する場合 (そして、Rex M. が指摘したように、主にレプリケーション シナリオで、いくつかの非常に優れた用途があります)、OK ですが、クラスタリング キーとして INT IDENTITY 列を使用するようにしてください。 SQL Server を使用して、インデックスの断片化とパフォーマンスの低下を最小限に抑えます。
「SQL Server インデックス作成の女王」である Kimberly Tripp には、このトピックに関する非常に優れた洞察に満ちた記事がたくさんあります。私のお気に入りのいくつかを参照してください。
基本的に、彼女がブログで公開したものはすべて読む価値があります。