ASP.NET メンバーシップ機能に BIGINT を導入してユーザーを一意に参照し、その BIGINT フィールドを tenant_id として使用するには、どのような方法がよいでしょうか? GUID の形式で UserId を生成する既存の機能を保持し、ゼロからメンバーシップ プロバイダーを実装しないことが理想的です。アプリケーションは複数のサーバーで実行されるため、BIGINT tenant_id は一意である必要があり、これらの ID を生成する中央機関に依存してはなりません。これらの tenant_id を SPLIT AT コマンドで使用するのは簡単です。これにより、ユーザーを新しいフェデレーション メンバーにバケット化できます。これについて何か考えはありますか？
ありがとう
bigint を使用できます。ただし、ユーザー ID に依存するすべてのストアド プロシージャを変更する必要がある場合があります。通常、ID をグローバルに一意にすることは問題になりません。ID が主キーである限り、データベースはそれを一意に強制します。そうしないと、新しいデータを挿入するときにエラーが発生します (その場合、ID を変更して再試行できます)。
したがって、最も重要な違いは、ストアド プロシージャの変更が必要になる場合があることです。ここで選択肢があります。GUID を使用する場合は、何もする必要はありません。ただし、フェデレーションを分割してクエリのバランスをとる方法を予測するのは難しい場合があります。別のスレッド (http://stackoverflow.com/questions/10885768/sql-azure-split-on-uniqueidentifier-guid/10890552#comment14211028_10890552) で指摘されているように、既存のデータを中間点で並べ替えることができます。しかし、将来のデータがどのフェデレーションに挿入されるかはわかりません。フェデレーションが不均衡になる潜在的なリスクがあり、それらを一定の間隔でマージおよび分割して形を保つ必要がある場合があります。
bigint を使用すると、キーをより適切に制御できます。たとえば、2 つのフェデレーションがあるとします。最初の ID は 1 から 10000 まで、2 番目の ID は 10001 から 20000 までです。新しいユーザーを作成するときは、最初に各フェデレーションにいくつのレコードがあるかを確認します。フェデレーション 1 に 500 のレコードがあり、フェデレーション 2 に 1000 のレコードがあるとします。負荷を分散するために、フェデレーション 1 に挿入することを選択し、1 から 10000 の間の ID を選択します。手順。