1

複数のクライアントとサーバー環境にまたがる、常時接続されていない分散型データベースを持つ最善の方法は何ですか?

私は、分離された Windows クライアントを持つマルチテナント Web アプリを構築しています。システム内のエンティティには、連絡先、タスク、アクティビティなどが含まれます。これらのエンティティの多くは、サーバーから切断されている間にクライアント側で作成されます。クライアントがスタンドアロン モード (現在のバージョン) で動作している場合、クライアントはサーバーに接続できません。

ここで、エンティティがクライアントで作成されたときに、サーバー側で競合が発生しないようにしたいと考えています。これは、GUID を主キーとして使用するのに最適な仕事のように見えます。エンティティの数が少ないクライアント側では問題にはなりませんが、サーバー側では潜在的に問題になるのではないかと懸念しています。 GUID のランダムな性質により、ルックアップが非常に非効率になります。

さらに、どの時点 (つまり、どのテーブル) で、主キーで GUID を使用する必要がなくなったのですか? たとえば、タスクに一連のメモ (1:N) があるとします。メモについて特に特別なことは何もありません。アクセス可能 - これらの種類のエンティティをキーイングする効率的な方法はありますか?

4

3 に答える 3

3

GUIDを使用する場合、新しいデータをインデックスに挿入する場合にのみ、ルックアップでパフォーマンスが低下することはありません。また、dbmsがGUID値をどのように処理するかにも依存します。

とにかく、少なくとも転送IDとしてGUIDを使用することをお勧めします。

于 2012-10-12T18:08:36.320 に答える
1

ここで、エンティティがクライアントで作成されたときに、サーバー側で競合が発生しないようにしたいと考えています。これは、GUID を主キーとして使用するのに最適な仕事のようです。

GUID は、各行が一意であることを保証します。しかし、通常、一意の行は実際の問題ではありません。

テナントが会社の場合、会社の ID 番号が各行に表示されます。同じ会社の 2 人のユーザーが、GUID のみが異なる行を挿入する可能性がある場合でも、潜在的な競合に対処する必要があります。

たとえば、州のテーブルにデータを入力する 2 人のユーザーがいる会社を想像してみてください。

              guid    employer_id  state_code  state_name
              --
user1 enters  guid-1  12345        AL          Alabama
user2 enters  guid-2  12345        AL          Alabama

データの整合性には、GUID 列の主キー制約だけでなく、より多くの制約が必要です。(特に、切断されたクライアントが、外部キー参照によって関連付けられた他のテーブルにデータを入力している場合。)

GUID をクラスター化されたキーにする必要はありません。一部の dbms は、デフォルトで主キーをクラスター化されたキーにします。あなたの dbms がそれを行う場合、おそらくyour_column_name guid primary key nonclustered.

于 2012-10-16T15:00:37.630 に答える