私たちは、リレーショナルオブジェクトモデルを持つプロジェクトに取り組んでおり、データストレージの一部にはno/sqlソリューション(couchdb)を使用したいと考えています。例えば、アプリケーションのUserIdフィールド(またはDDDの世界ではUserプロパティ)を介して互いに関連するユーザーとアプリケーションがあります。nosqlの世界でリレーショナルPOCOを保存する方法は?
「アプリケーション」ドキュメントのcouchdbに「ユーザー」データを格納する正しい方法は何ですか?関係のidか "user"オブジェクト全体を "application"ドキュメントに入れるか?アプリケーション文書に「ユーザー」オブジェクト全体を配置すると、ユーザーを更新すると、内部にユーザー情報がすべて含まれているすべてのアプリケーション文書が更新されます。
私はちょっと混乱していますので、私はそれについていくつかのアイデアを聞いてとてもうれしく思います。
ありがとうございます。
詳細な回答ありがとうございます。あなたは、どんな種類のモデルが、TwitterやFacebookなどのソーシャルジャイアントで使用されているのか考えていますか?例えば、私がtwitter APIドキュメントをチェックすると、ほとんどのAPI関数はIDなしで "ドキュメント"を返します。これは、実行時にidを実際の "関連ドキュメント(オブジェクト)"に置き換え、jsonに変換した後にユーザーに返すということですか?あるいは、ドキュメントに実際の「関連オブジェクト」を格納していて、パワフルなサーバーで遅い/複雑な書き込みなどの問題を解決していますか?ありがとうございました! –
apiのようなものは、基盤となる構造にはあまり関係ありません。大規模な公開APIの場合は、公開する必要のないデータを公開する必要はありません。巨人は、実際にはきれいなアーキテクチャを実際に探し出す最良の場所ではありません。数年のコードを更新することからくる複雑な問題はすべてあります。また、キャッシュと最適化のトンネルを持つmysqlのコアを持っていると思います最初から開始する場合はスタンドアロンで使用できるnosqlコンポーネント。 –
したがって、文書内に関係のためのIDまたは一部の識別子フィールドを入れることは許容されます。 idを実際のオブジェクト値に置き換えるために何か追加作業をすることについてどう思いますか?私は、実行時に置換を検出するためにいくつかのカスタム属性を置かなければならないと思います... –