次の場合、リレーショナル データベース モデルに使用するのに最適な主キー戦略はどれですか?
- 数万人のユーザー
- ユーザーごとに複数のクライアント (電話、タブレット、デスクトップ)
- テーブルごとに数百万行 (継続的に増加)
Azure SQL は、Web API を介して公開される中央データ ストアになります。クライアントには、Web アプリケーションと、iOS、Android、Mac、Windows 8 などの多数のネイティブ アプリが含まれます。Web アプリケーションには、「常時接続」の接続が必要で、ローカル データ ストアはありませんが、代わりに取得と更新を行います。 API 経由 - RESTful API 経由の CRUD を考えてみてください。
他のすべてのクライアント (電話、タブレット、デスクトップ) には、ローカル データベース (SQLite) があります。このタイプのクライアントを初めて使用する場合、ユーザーは認証と同期を行う必要があります。認証と同期が完了すると、これらのクライアントはオフライン モードで動作できます (ローカル SQLite データベースでレコードを作成、削除、更新します)。これらの変更は、最終的に Azure バックエンドと同期されます。
データベースの分散された性質により、主キーの問題と、この質問をする理由が残ります。
これまでに検討した内容は次のとおりです。
GUID
各クライアントは独自のキーを作成します。同期時に、キーが重複する可能性は非常に低いですが、新しいキーですべての関係を更新する機能を各クライアントに書き込むことで、重複を考慮する必要があります。GUID は大きく、テーブルごとに複数の外部キーが考慮されると、時間の経過とともにストレージが問題になる可能性があります。おそらく最大の問題は、GUID のランダムな性質です。これは、断片化のためにクラスター化インデックスとして使用できない (またはすべきでない) ことを意味します。これは、テーブルごとに (おそらく任意の) クラスター化インデックスを作成する必要があることを意味します。
身元
各クライアントは、独自の主キーを作成します。同期時に、これらのキーはサーバーで生成されたキーに置き換えられます。これにより、同期プロセスがさらに複雑になり、各クライアントは、関連するテーブルのすべての外部キーを含むキーを「修正」する必要があります。
複合
各クライアントには、最初の同期時にクライアント ID が割り当てられます。このクライアント ID は、ローカルの自動インクリメント ID と組み合わせて、各テーブルの複合主キーとして使用されます。この複合キーは一意であるため、同期時に競合は発生しませんが、ほとんどのテーブルで複合主キーが必要になることを意味します。ここでは、パフォーマンスとクエリの複雑さが問題になります。
HiLo (複合コンポジット)
複合アプローチと同様に、最初の同期で各クライアントにクライアント ID (int32) が割り当てられます。クライアント ID は一意のローカル ID (int32) とマージされて単一の列になり、アプリケーション全体で一意の ID (int64) になります。これにより、同期中に競合が発生することはありません。各クライアントによって生成された ID は連続しているため、これらのキーと GUID にはより多くの順序がありますが、何千もの一意のクライアント ID があるため、クラスター化されたインデックスで断片化のリスクがまだありますか?
私たちは何かを見落としていますか？調査する価値のある他のアプローチはありますか? 各アプローチの長所と短所についての議論は非常に役に立ちます。