6

Visual Studio 2010 で ASP.NET Web サイトを開発しています (Service Pack 1 を使用して、どうもありがとうございました)。SQL Server 2008 で .NET の組み込みのメンバーシップ プロバイダーとロール プロバイダーを利用したいと考えています。

現在、私は非常に長い間 Microsoft テクノロジの開発に携わっており、業界で最も優れた SQL Server DBA の何人かと交流を深めてきました。次のようなデータベース テーブルを作成するときは、主キーとして GUIDS を使用しないようにと、全員が私に言いました。

  1. 非常に高いレコード数を持っています。
  2. 大量の挿入と削除があります。

理由: 主キーがクラスター化インデックスであるためです。

これは基本的に、テーブルに挿入される各レコードがインデックスの制約に従う必要があることを意味します。したがって、インデックスが ASC で並べ替えられている場合、新しく生成された GUID を持つレコードは、適切な順序で問題のデータ テーブルに物理的に押し込まれなければなりません。

これは、数千件程度のレコードしかないテーブルでは問題ありません。SQL Server は、ほんの一握りを再配置するだけで済みます。ただし、データ テーブルに数百万のレコードがあり、行 216 に新しいレコードを挿入する必要があることがわかった場合は、完了するまでにかなりの時間がかかる可能性があります (Web 標準によると)。新しい行を挿入するには、これらすべての行を物理的に下に移動する必要があります。

だから私の質問は単にこれです。Microsoft と、私たちが知っていて愛するすべての DBS は、主キーとしての GUID に NO と言ってきました... ASPNET_REGSQL ツールは、GUID を主キーとして使用してテーブルを作成するのはなぜですか?

または、何か不足していますか?2008 年の SQL プロファイラー エンジンに、GUIDS をタスクと見なさない新機能はありますか?

4

2 に答える 2

3

ガイドにはいくつかの強みがあります。たとえば、アプリケーション コードで GUID を生成している場合、同じ ID になることを心配することなく、Web ファームで GUID を生成できます。もう 1 つの利点は、ランダムに選択された 2 つの行がデータの同じページに存在する可能性が低いため、問題を引き起こすことなくデータベースのページをロックできることです。

数百万行のデータについてあなたが言ったことに関する限り、SQLサーバーに単一行のデータを返すように常に要求している限り、Guidは問題ありません。最大の問題は、データの大きなサブセットを要求する場合、または多数の行をバッチで挿入する場合です。次に、条件に一致するすべての行を取得するか、ガイドが最終的に指すランダムな場所にすべての行を挿入するために、多くのランダム I/O を実行する可能性があります。また、SQL は「物理的にすべての行を下に移動して、新しい行を挿入する」必要はありません。データはページに保存され、SQL は通常、データ ファイル内の 1 ページのデータを変更して行を挿入するだけでよく、場合によっては他のいくつかのページを更新しますが、大規模なテキスト ファイルに行を挿入するのとは異なります。

そうは言っても、私は通常、主キーには整数を好みますが、GUID が意味をなす状況が確実に存在することを指摘したかっただけです。

于 2011-04-26T01:51:24.903 に答える
1

GUID を主キーとして使用しても問題はありません。確かに、適切に使用しないと、いくつかの不利益を被る可能性がありますが、店舗やその他の販売時点でさまざまなデータベースがあり、毎晩、各場所からすべてのデータを取得して単一のデータベースに結合する必要があるシナリオを考えてみてください。企業のマスター データベース。ID の競合について心配する必要がないため、ここでは GUID が優れたオプションです。

データベースを構築するときは、主キーとして GUIDS を使用しないようにとのことです。主キーはクラスター化されたインデックスだからです。

主キーはクラスター化インデックスを使用する必要はありません。クラスター化インデックスは、主キーの作成時に使用される既定のインデックスの種類です。

実際、 で使用されるデータベース スキーマを見ると、主キー列に非クラスター化インデックスSqlMembershipProviderあることがわかります。

以下は、 のスクリプトの SQL スクリプトInstallCommon.sqlです%WINDIR%\Microsoft.NET\Framework\v4.0.30319

  CREATE TABLE [dbo].aspnet_Users (
    ApplicationId    uniqueidentifier    NOT NULL FOREIGN KEY REFERENCES [dbo].aspnet_Applications(ApplicationId),
    UserId           uniqueidentifier    NOT NULL PRIMARY KEY NONCLUSTERED DEFAULT NEWID(),
    UserName         nvarchar(256)       NOT NULL,
    LoweredUserName  nvarchar(256)       NOT NULL,
    MobileAlias      nvarchar(16)        DEFAULT NULL,
    IsAnonymous      bit                 NOT NULL DEFAULT 0,
    LastActivityDate DATETIME            NOT NULL)

   CREATE UNIQUE CLUSTERED INDEX aspnet_Users_Index ON [dbo].aspnet_Users(ApplicationId, LoweredUserName)
   CREATE NONCLUSTERED INDEX aspnet_Users_Index2 ON [dbo].aspnet_Users(ApplicationId, LastActivityDate)

主キー列 ( UserId) はステートメントPRIMARY KEY NONCLUSTEREDを使用して作成され、テーブルのCLUSTEREDインデックスは と の複合インデックスとして作成されることに注意しApplicationIdてくださいLoweredUserName

于 2011-04-26T02:24:22.727 に答える