私は現在、SQLAzureデータベースを使用して次のアプリケーションのデータを格納するプロジェクトに取り組んでいます。プロジェクトの目標の1つは、SQL Azureでフェデレーション（シャーディング）を利用できるようにすることです。プロジェクトのもう1つの目標は、クライアントがこのシナリオを選択した場合に、ローカルハードウェアでこのアプリケーションを実行できるようにすることです。
私が直面している「障害」の1つは、フェデレーションにおけるIDENTITYのサポートの欠如です。
AzureでIDENTITYがサポートされていない理由は理解していますが、クラスター化されたインデックスとしてGUIDを使用することをお勧めするという精神的な障害があるようです。
クラスター化インデックスと非クラスター化インデックスのパフォーマンス
上記の最初のリンクでサンプルテストを実行し、クラスター化されたインデックスとしてGUIDを使用してテーブルにレコードを挿入する場合と、クラスター化されたインデックスを使用して同じ量のレコードをテーブルに挿入する場合で、Azureのパフォーマンスにほとんど違いがないことを確認しました。クラスタ化されたインデックスとして機能するintIDフィールド。
ただし、オンプレミスインストールもサポートする必要があるため、int IDを使用する代わりに、クラスター化されたインデックスとしてGUIDを使用すると、ローカルでのパフォーマンスが低下すると言っても差し支えないと思います。
パフォーマンス関連の懸念に加えて、クラスター化されたインデックスとして16バイト幅のGUIDを使用するのに対して、クラスター化されたインデックスとして4バイト幅の整数を使用することについても懸念しています。確かに、ディスク容量は比較的安価ですが、それでもかなり急速に増加します（そしておそらく不必要にそうなります）。
私は、これらの述べられたプロジェクトの目標の両方をサポートする必要性に基づいて、最終的にトレードオフを行う必要があることを認識していますが、私はできる限り多くの情報に基づいた決定を下すことを目指しています。
中間層のIDジェネレーターを使用する以外に、フェデレーションを使用しながらAzureでクラスター化インデックス（および\または主キー）としてGuidを使用する代わりにどのような方法がありますか？
または、Guidをクラスター化されたインデックスのオフベースとして使用することに関する私の懸念はありますか（私はそれらが非常にうまくいく可能性があることを認めています）？もしそうなら、なぜですか？