多くの開発者と同様に、既存のアプリを SQL Azure フェデレーションに統合する方法を探していますが、Identity 列 (テーブルの主キー) を置き換えることは大きな問題です。
多くの理由から、主キーに GUID を使用したくありません (GUID についての議論を開かないでください。それは私の質問ではありません: GUID が必要ないだけです)。
そのため、標準 SQL データベースの「ID」機能を置き換えるキー プロバイダーを構築する必要があります。私は Entity Framework を使用しているので、 (クラスのメソッドをIdオーバーライドすることによって) 挿入の直前に値を設定する場所を簡単に見つけることができます。「ファーム対応」である現在の Id を取得するための「あまり複雑ではない」実装を見つける必要があるだけです。SaveChangesObjectContext
この SO 投稿を読みました:「シャード データベース (Azure Federated Database) の ID 生成」および「 MSDN Magazineの Windows Azure で複数のノードを同期する」ですが、この解決策は私にとって少し複雑に思えます。
SQL テーブルごとに 1 つの Azure キューを (自動的に) 作成することを考えています。これには、事前に読み込まれた連続する整数のリストが含まれています。Id 値が必要な場合は、キューからメッセージを取得するだけで (非表示になり、途中で削除されます)、現在使用可能な Id が得られます。
"Windows Azure Queues" と "Windows Azure Service Bus Queues" のどちらを選択するかについては、Service Bus Queues の"高い" 待ち時間のため、"Windows Azure Queues" を好みます。Azure Queues の「注文保証」がないことは問題ではないと思います。
Azure キューを使用して Id 値を提供するというアイデアについてどう思いますか? その考えを放棄する議論はありますか? SQL Azure フェデレーション データベースで整数 ID を提供するためのより良いアイデア、または良い習慣はありますか? ありがとう。
編集 ：
Astaykov は SnowMaker を提案しました。Azure Storage lib の v2 との完全な互換性を確保するために、SnowMakerのフォークを最終的に行いました。
編集2
ここで説明されているように、 Azure SQL フェデレーションは 2015 年 9 月に Web 層とビジネス層で廃止されることに注意してください。しかし、この質問は、カスタム シャーディング ソリューションにも当てはまります。