いつSQL Azureを使用する必要があり、いつテーブルストレージを使用する必要がありますか？
いつSQL Azureを使用する必要があり、いつテーブルストレージを使用する必要がありますか？私は考えていました、トランザクション処理シナリオにはテーブルストレージを使用してください。クレジットアカウントのシナリオをデビットし、データがトランザクション目的（レポートなど）に使用されない場合はSQL Azureを使用します。どう思いますか？
これはすばらしい質問であり、ソリューションアーキテクトがAzureを設計する際に決定を下すのは困難で難しい決定の1つです。
考慮すべき複数の次元があります：マイナス面として、SQL Azureはギガバイトのストレージに対して比較的高価であり、拡張性が非常に低く、データベースあたり150ギガに制限されていますが、これは非常に重要であり、SQLに対するトランザクション料金はありませんAzureと開発者は、それに対するコーディング方法をすでに知っています。
ATSはすべてが異なる動物です。メガスケーラビリティに対応しているため、保存するのは簡単ですが、頻繁にアクセスすると高額になります。また、操作するためにノードからかなりの量のCPUパワーを必要とします。すべてのリレーショナルアクティビティの委任が委任されると、基本的には計算ノードがミニdbサーバーになることを強制します。
したがって、私の意見では、巨大なスケーラビリティを必要とせず、サイズがそれほど大きくない、頻繁にアクセスされるデータは、SQL Azure、それ以外の場合はAzure Table Servicesを宛先とする必要があります。
具体的な例として、金融取引の取引データはATSに最適な場所ですが、メタ情報（アカウントプロファイル、名前、住所など）はSQL Azureに最適です。
イゴールとマークは素晴らしい答えを出しました。もう少し追加しましょう...
SQLデータベース（以前の名前はSQL Azure）では、最大500 GBのデータベースを使用できます。それを超えるには、データを分割する必要があります。 注：最初はSQLフェデレーションのシャードを提案しましたが、この機能は廃止されました。
ATSは、パーティションレベルのトランザクション（エンティティグループトランザクション）を提供します。詳細については、 このMSDN記事 を参照してください。これはSQL Azureトランザクションほど堅牢ではありませんが、単一のトランザクションでバッチ操作を行うことができます。
[〜＃〜] edit [〜＃〜]この質問が尋ねられて（そして答えられて）から1年以上が経過しています。比較ポイントの1つは価格設定でした。 SQL Azureは依然としてATSよりも高価ですが、SQL Azureのコストは過去1年間で大幅に減少しています。データベースの階層化された価格は100MBで$ 4.99から始まり、150GBで$ 225に増加しました（昨年の$ 9.99/GBの価格から大幅に低下しました。完全な価格の詳細は こちら です。
EDIT 2014年8月1年後、別のアップデート。 Web /ビジネス層は引き続き存在しますが、廃止される予定です（SQLフェデレーションは利用できなくなります）。新しいベーシック、スタンダード、およびプレミアム階層が利用可能になりました（詳細については こちら を参照）。
これらの回答の一部は完全ではないようなので、2セント追加します。
Azureテーブルの良い点：
- 強力な点は、大量の小さなデータを保存できることです。 AzureテーブルはAzure Blobに基づいていますが、より小さなデータを対象としています
- Azure SQL Serverよりもはるかに安価
- パーティションキーと行キーの両方を知っているときはいつでも、データアクセスは非常に高速です。
Entity transactionsは、2つの異なる「スキーマ」を同じパーティションキーに配置した場合に可能です。- 行の合計サイズが980K未満（SQL行）の場合
- 各プロパティが64K未満（SQL列）
- それは貧しい人のSQLとして機能することができます。
Azureテーブルの悪い点：
- SQLが弱点です。大きなSQLテーブルではこれを使用しないでください。パフォーマンスの問題が発生します。
- 限られたSQLが利用可能であり、Linqで実装するもの以外に、どのタイプの結合も期待しないでください。
- Azure Table SQLは、無制限の量のデータを格納する機能だけでなく、拡張もしません。
- WHERE句でパーティションキーと行キーの両方を指定しない場合は常に、低速のテーブルスキャンが発生することが予想されます。
- さらに行を追加すると、テーブルスキャンのパフォーマンスが低下することが予想されます
- 行を追加するときにAzue Tableクエリが高速になるとは期待しないでください
- つまり、Azure Tableを使用してSQLのように動作している場合は、大量のデータを追加しないでください。大量のデータ（ギガバイト）がある場合は、そのデータに対して高性能のSQLクエリを取得することを計画しないでください。これらの通常のSQL機能が必要ない場合は、費用を節約できます。
トランザクションに関しては、その逆です。SQLAzureはトランザクションをサポートしています。テーブルストレージはサポートしません。
SQL Azureは基本的にWindows Azure内で実行されるSQL Serverであるため、SQL Serverを使用する既存のアプリケーションがある場合、SQL Azureは適切な移行パス。ただし、SQL Azureで使用できるデータベースの大きさ（現在150 GB）には制限があるため、データベースをどれだけ拡張できるかには制限があります。
一方、テーブルストレージは非常にスケーラブルですが、別の考え方が必要です。それはリレーショナルデータベースではありません。たとえば、素敵な紹介のためのこの記事： http://msdn.Microsoft.com/en-us/magazine/ff796231.aspx
本当の答えは、「Azure Table Storageを使用しないように本当に頑張ってください」です。リレーショナルDBからSQLを使用しないDBに移行する場合は、ストレージアーキテクチャに対する考え方を変更する必要があります。しかし、ATSの問題は、「別の方法で考える」ことを必要とする以上のものです。他の人々が指摘したように、これは単なる「No-SQL」データストアではなく、No-SQLストアの特に発育不良でハンディキャップがあり、機能が非常に低いインスタンスです。 ATSについて「違う考え方」をする必要はありません。それは、ATSがあなたの仕事に必要なツールを提供していない問題です-他の非SQLデータストアdoが提供するツール。
ATSの唯一の良い点は、最小限のストレージ料金で非常に迅速に大量のデータをそこに入れることができることです。ただし、運が良ければ、パーティションキー/行キーストレージモデルに魔法のように一致するユースケースが得られない限り、基本的にそのデータを再度取得することはできません。そうしないと-非常に少数の人がそうだと思う-あなたは多くのパーティションスキャンを行い、自分でデータを処理することになります。
それ以上に、Azure Table Storageは開発の点で行き止まりのようです。 Azureフィードバックフォーラムで「セカンダリインデックスのサポート」リクエストを確認した場合（ http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes ） 、2011年までセカンダリインデックスのサポートが約束されていたことがわかりますが、進展はありません。また、テーブルストレージに対するその他の上位の要求についても、進展はありません。
さて、スコットガスリーは質の高い人であることを知っているので、テーブルストレージのこの停滞はすべて、Azureがこれを修正し、本当にすばらしいものを生み出す前置きであることを望んでいます。それが私の希望です（ただし、そのような証拠はありません）。ただし、現時点では、選択肢がない限り、Azure Table Storageを使用しないことを強くお勧めします。 Azure SQLを使用します。 MongoDBの独自のインスタンスまたはその他のNo-SQL DBを使用します。またはAmazon DynamoDBを使用します。ただし、Azure Table Storageは使用しないでください。