私は、asp_membership が uniqueidentifier を使用していることに気付きました。私には、スペースの無駄のように思えました。これを ID に置き換えない特別な理由が思いつかなかったからです。
ただし、SQL Server では int に変更できません。「接続されたデータベース サーバーでは、uniqueidentifier から int への変換はサポートされていません」と表示されます。グーグルで調べた後、すべての関係などを壊してから、列を手動で削除してintとして再度追加する必要があるようです。より良いアプローチを知っていますか？
複数のデータベースを扱うことはないと思うので、uniqueidentifier は不要のようです。同意しますか？
注意してください: 私は新しい Web アプリケーションを開始しています。これを修正するのは難しいと思いますか？
また、主キーは URL の一部ではないことに注意してください。
私のアドバイスは、そのままにしておくことです。あなたがそれを取り除くために（あなたが説明したように）多くの仕事に行く必要があるという事実については正しい. なんで？機能するものを台無しにするのはなぜですか？データベースのスペースを節約するには? 最近のストレージと同じくらい安価で、ハード ドライブまたはストレージ アレイの平均サイズを考えると、スペースの節約量はまったく取るに足らないものです。
このアイデアには投資収益率はありません。
UNIQUEIDENTIFIER 列を INT に変換することはできません。この場合に必要なことは次のとおりです。
もちろん、「UserID」は主キーであり、多くの場所から参照されるため、UserId 列を削除できるようになる前に、多くのハウスキーピングを行う必要があります。
UNIQUEIDENTIFIER が SQL Server テーブルの主キーおよびクラスタリング キーにとって本当に悪い選択であるというあなたの考えと実現を称賛しますが、この特定のケースでは、おそらく「そのまま」にしておくと思います-変換しようとすると、 ASP.NET テーブル全体で多くのリップルの変更が行われます。おそらく、努力する価値はありません。
マルク
Uniqueidentifierとintは、非常に異なるデータ型です。guidをintに変更することはできません。すべての関係を削除し、親テーブルに数値を割り当て、すべての子テーブルに数値列を追加し、結合を使用して子テーブルのすべての値を設定する必要があります。すべてのguid列を削除し、int列を主キーにします。すべての関係を設定します。
また、データベースと通信し、整数値で動作できるように値がGUIDであることを期待するすべてのアプリを変更することは言うまでもありません。
あなたはごくわずかな利益のために多くの仕事を見ています。
はい、GUIDは連続しておらず、数値は連続しているため、パフォーマンスがいくらか向上します。しかし、これからいくつかの主要なパフォーマンスの問題が発生しない限り、実際に変更を加える理由はそれだけでは十分ではありません。
少なくとも、何週間もの作業とテストを見ているでしょう。実際には、考えられるあらゆる小さな変化を確実に捉えるために数か月かかります。