問題タブ [azure-cosmosdb]

Employees という DocumentDb コレクションから特定のドキュメントを削除しようとしています。次のコードを実行すると、「タスクがキャンセルされました」というエラーが表示されます。

私は何を間違っていますか？

DocumentDb で、データを分離して別のコレクションに保存するための最良の方法と場所は何ですか?

これまでのところ、DocumentDb を使用してデータを管理する方法の例のほとんどは単純なオブジェクトを使用していますが、実際にはほとんど使用していません。DocumentDb に Json オブジェクトとして保存する前に、複雑なクラスを処理する方法と場所を理解したいだけです。

次の例を見てみましょう。プロジェクト情報を Projects コレクションに保存しますが、プロジェクト チームのメンバーのフル ネームをプロジェクト ドキュメント内に保存したくありません。EmployeeId をプロジェクト ドキュメントに保存したいだけです。個人/従業員固有の情報を保存する別の Employees コレクションがあります。私のプロジェクト オブジェクトは次のようになります。

私の TeamMember クラスは Employee オブジェクトから継承され、次のようになります。

私の従業員クラスは次のようになります。

Projects コレクションに保存する前の Project ドキュメントの例を次に示します。

ご覧のとおり、プロジェクト情報を従業員データから切り離して、それぞれ独自のコレクションである Projects コレクションと Employees コレクションに格納しました。

なぜデータを切り離すべきなのか、あるいは切り離すべきなのかについては触れません。最速の結果を得るために、デカップリングをどこでどのように処理する必要があるかを確認したいだけです。ベスト プラクティスに従いたいので、DocumentDb を扱う専門家がこのシナリオをどのように処理するかを知りたいだけです。

これを処理する 2 つの場所を考えることができますが、これを行うためのより良い、より直接的な方法があるかどうかを理解したいと思います。

1. C# コード内で Project クラスを JSON オブジェクトに変換し、JSON オブジェクトを DocumentDb に渡して保存することができます。
2. または、Project オブジェクトを直接 DocumentDb の JavaScript ストアド プロシージャに渡し、DocumentDb 内の 2 つ以上のコレクションにデータを分離して格納することもできます。

知りたいことは次のとおりです。

1. デカップリング データを処理するのに適切な場所はどれですか?
2. どちらがより良いパフォーマンスを提供しますか?
3. これを処理するより良い方法はありますか？POCOクラスをDocumentDbに渡すだけで、それらを処理してくれる方法について読み続けています。DocumentDb は、このより複雑なシナリオを処理できますか? もしそうなら、どのように？

私はあなたの助けに感謝します。ありがとうございました。

DocumentDB でストアド プロシージャを作成し、後で必要なときにいつでも使用したいと考えています。ストアド プロシージャを実行するには、storedProcedureLink を知る必要があります。CreateStoredProcedureAsync メソッドでストアド プロシージャを登録すると、リンクが表示されます。後でこのストアド プロシージャを実行する場合、このリンクを自分のどこかに保存する必要がありますか? プロシージャ名しか知らない場合、ストアド プロシージャを実行できますか? 私が見つけたすべての例から、ストアド プロシージャを実行する直前に作成して登録する必要があるようですが、そうですか?

Azure で実行される ASP.NET MVC 5 アプリを構築しています。データの管理に DocumentDb と Azure Table Storage を使用しています。

メッセージ キューではなく、HTTP を使用して Web ロールから呼び出す Azure Worker ロールに DAL 関数を移動することを考えています。

通常、worker ロールは時間に依存しないバックエンド ジョブに使用されると思いますが、DAL を HTTP 要求に応答する worker ロールに移動できなかった理由はわかりません。これにより、データレイヤーを適切に分離し、スケールアップ/スケールアウトするのが非常に簡単になると思います。

これは、追加の作業処理データを必要とする DocumentDb と Azure Table Storage に切り替えて以来、私にとってさらに理にかなっています。Worker ロールは、はるかに簡単にスケールアップできるため、余分な作業をすべて処理するのに理想的であると考えました。

とにかく、これについて他の人の提案と視点を得たかったのです。ご意見をお聞かせください。

documentDb の C# poco のデフォルトのシリアル化を変更することは可能ですか? たとえば、id プロパティは小文字にする必要があるようですが、Id プロパティのデフォルトのシリアル化は大文字です。理想的には、すべての json プロパティを小文字で開始する必要があります。これまでに見つけた唯一の方法は、プロパティを [JsonProperty(PropertyName = "id")] で装飾することですが、あまりエレガントではありません。

DocumentDb ドキュメントに、NULL 値を持つプロパティを含めたくありません。たとえば、次の POCO クラスがあります。

ミドル ネームを持たない人もいますが、その人物のドキュメントをコレクションに保存するときに、ミドル ネームを含めたくありません。現在、ミドルネームのない人物は次のように保存されています。

これは正常な動作ですか？そうでない場合、ドキュメントに NULL 値を持つミドル ネーム プロパティを含めないようにするにはどうすればよいですか?

PS すべてのシリアライゼーション/デシリアライゼーションは JSON.NET によって処理されます

DocumentDB のクライアント側の JavaScript API で遊んでいます。コレクションを照会できるようにしたい。「 https://mydocumentdb.documents.azure.com:9443/dbs/my_db/colls/my_users 」のようなコレクション URL を使用したいのですが、documentdb をクエリするための API 関数がないようです最初にデータベースの「自己リンク」を取得せずにコレクションを取得し、次にコレクションの「自己リンク」を取得します。これらの自己リンクを取得する唯一の方法は、最初にすべての DB を反復処理してから正しい自己リンクを取得し、次にコレクションを反復処理してコレクションを取得し、最後にサービスから取得した自己リンクを使用してクエリを実行することです。コレクション。

本当？？？