大きな（128ビット）PKを保存する必要があります。各intには、対応する列がいくつかあります...現在スキーマは定義されていません...そして将来的にはスキーマを柔軟にしたいと考えています。（私は控えめな柔軟性だけが必要です。たとえば、時々新しい列を追加します）
この時点では、結合などを実行する機能についてはあまり心配していません。私は主にランダムなPKを選び、次の10レコードまで検索したいと思っています。検索には多くの空白が含まれる可能性があるため、上向き検索と下向き検索のコストは異なる場合があります。
このリクエストを処理するための最良のテクノロジーは何ですか？お金（トランザクションごと）とストレージスペースを節約できるものに興味があります。パフォーマンスにも興味があります。
おすすめは何ですか？
アップデート
さて、これは何のためですか？IPv6アドレスのデータ履歴を作成したい。もちろん、これは非常にまばらなテーブルになります...しかし、私は見られたIPに関して特定のことを追跡する必要があります。
明確にするために、128ビット（2 ^ 128ビットではない）のキーが必要だと思います。
これをDbキーの種類の選択に関する質問として取り上げていますが、Azureの角度がどのような結果をもたらすかはわかりません。AFAIKは、MS-SQLの上に構築されています。
128ビットまたは16バイトはGuid（UniqueIdentifier）と同じサイズですが、それを使用したくないと思います。キーとして使用するためのサポートがありますが。
直接の選択はbinary（16）のようなものですが、それがPKとしてどれほど適しているかはわかりません。
過度ではないchar（32）16進文字列としてコーディングできます。
実用性の見積もりでは、重要な要素はデータがどれだけまばらであるか、またはそれ以上であるかです。つまり、格納する必要のあるアドレスの数はいくつですか。
Windows Azure Tables をお勧めしますが、定義されている並べ替え順序が 1 つしかないため、前方と後方の両方を検索するのは困難です。両方のスキャン方向を効率的にサポートするために、各キーを 2 回、1 回は通常の順序で、もう 1 回は逆順 (0xFFF...F - キー) に保存する必要がある場合があります。
まず第一に、IP V6アドレスを保存したいと述べたので、2 ^ 128整数キーの前提は間違っています。IP V6 アドレスは 128 ビット長です。整数として格納するには、アドレスごとに 128/32 または 4 つの 32 ビット整数が必要です。したがって、正しい見積もりは、2^128 の可能なアドレス * 4 つの整数で、合計で 2^128 * 32 ビット整数の 4 つのキーになります....
とにかく、私はそれをバイト単位で求めているので、2^128 の可能なアドレス * 4 つの整数 * 整数あたり 4 バイト = 5.44 * 10^39 バイトになります。その後、アンドレアスの計算に従うだけで、さらに多くの結果が得られます....
そうは言っても、IP V6 の考え方は、使用する必要があるよりも多くのアドレスを持つということです。したがって、2^128 に近い値が何年にもわたって割り当てられるとは思えません。せいぜい今 IP V6 に移行すると、IP V4 アドレス空間が割り当てられるだけで、IP アドレスの数は毎年増加しますが、それほどではありません。
とにかく、スキーマが定義されていないため、何を保存しているのかわからないように思われるため、Azure テーブルが必要な場合があります。ほとんどの場合、キー/値です。IP アドレスごとに、まったく異なるプロパティを保存できます。また、更新/挿入/マージ操作を使用して、別のプロパティを追加したり、別のプロパティを削除したりするのは非常に簡単です。ただし、SQL を使用するよりもデータに均一性を適用したい場合。変更が発生したときにスキーマを変更する必要があるのは事実ですが、これにより、すべての行 (したがって IP アドレス) が同じデータを持つことが強制されます。そうしないと、「必要な」列/プロパティを省略したり、複数のアプリケーションがある場合にそれらのスペルを間違えたりするのは簡単です。しかし、それは本当にあなたが何をしたいかによって異なります。これ' データの整合性を重視しますか、それともプロパティの柔軟性を重視しますか? スキーマを変更する必要がありますが、スキーマから列を追加/削除するコマンドがあります。すべての IP アドレスに同じプロパティを格納するか、それぞれに異なるプロパティを持たせるかが重要です。特定の IP アドレスのほとんどのプロパティを使用していない場合、Azure テーブルの方法は、おそらく SQL の方法よりもアドレスごとに必要なストレージが少ないと思います。したがって、それはすべてあなたが探しているものに依存します。