Azure Table Storageの経験がある人が、1つのテーブルを使用して複数の種類を格納するのが良いかどうかについてコメントできるかどうか疑問に思っています。
これをやりたいのは、取引ができるようにするためです。ただし、開発の観点からも理解したいのですが、このアプローチは扱いやすいのでしょうか、それとも面倒なのでしょうか。これまでのところ、Azure Storage Explorerを使用して開発を支援しており、1つのテーブルで複数の種類を表示するのは面倒です。
例を挙げると、ブログのコミュニティサイトを設計しているとすると、すべてのブログ投稿、カテゴリ、コメントを1つのテーブルに保存すると、どのような問題が発生しますか？一方、そうでない場合、たとえば、カテゴリと投稿の一貫性を確保するにはどうすればよいですか（1つの投稿に1つのカテゴリを含めることができると仮定します）。
または、テーブルストレージを使用してこの問題を回避するために人々が取る他の異なるアプローチはありますか？
ありがとうございました。
完全な一貫性を保つことが目標である場合は、単一のテーブルを使用するのが良い方法です。しかし、あなたはおそらく自分自身にとって物事をより困難にし、報酬をほとんど得られないだろうと思います。私がこれを言う理由は、テーブルストレージが非常に信頼できるからです。トランザクションは素晴らしく、非常に重要なデータを処理している場合はすべてですが、ブログなどのほとんどの場合、1）一貫性のないデータのごくわずかな割合を許可し、2）失敗を処理する方がよいと思います。より手動の方法で。
同じテーブルに複数のタイプを格納する際に発生する最大の問題は、シリアル化です。現在のテーブルストレージSDKとユーティリティのほとんどは、単一のタイプを処理するように設計されています。そうは言っても、手動で（つまり、オブジェクトをすべての可能なプロパティを含むマスターオブジェクトに逆シリアル化する）、またはRESTサービスと直接対話する（つまり、Azure SDKを経由しない）複数のスキーマを確実に処理できます。RESTサービスを直接使用する場合は、シリアル化を自分で処理する必要があるため、複数の種類をより効率的に処理できますが、トレードオフとして、通常はAzureSDKで処理されるすべてを手動で実行します。
これを行う正しい方法も間違った方法もありません。どちらの状況でも機能します。それは、何が最も実用的かという問題です。個人的には、特に理由がない限り、テーブルごとに1つのスキーマを配置する傾向があります。テーブルストレージは、トランザクションを使用しなくても十分に信頼できると思います。
WindowsAzureToolkitを確認することをお勧めします。このツールキットは、より一般的な紺碧のタスクのいくつかを簡素化するように設計されています。