2010-12-19 13 views
0

私たちは、リレーショナルオブジェクトモデルを持つプロジェクトに取り組んでおり、データストレージの一部にはno/sqlソリューション(couchdb)を使用したいと考えています。例えば、アプリケーションのUserIdフィールド(またはDDDの世界ではUserプロパティ)を介して互いに関連するユーザーとアプリケーションがあります。nosqlの世界でリレーショナルPOCOを保存する方法は?

「アプリケーション」ドキュメントのcouchdbに「ユーザー」データを格納する正しい方法は何ですか?関係のidか "user"オブジェクト全体を "application"ドキュメントに入れるか?アプリケーション文書に「ユーザー」オブジェクト全体を配置すると、ユーザーを更新すると、内部にユーザー情報がすべて含まれているすべてのアプリケーション文書が更新されます。

私はちょっと混乱していますので、私はそれについていくつかのアイデアを聞いてとてもうれしく思います。

ありがとうございます。

答えて

0

どちらのアプローチも必要な読み書きに応じて有効です。ユーザーオブジェクトがほとんど変更されない場合は、遅く複雑な書き込みプロセスは関係ありません。追加することを避けることができますそれはアプリケーション文書にあります。それが大きく変わると、遅い/複雑な書き込みが支配的な問題になり、単にアプリケーション文書に参照を入れるほうが意味があります。これは実際にはSQLとNoSQLの大きな違いの1つです.SQLには正しい正規化された構造が1つあります.NoSQLを使用すると、より多くの要件について考える必要があります。

つまり、ユーザーはほとんど常にスタンドアロンオブジェクトとして理にかなっています。しかし、アプリケーションのドキュメントでユーザーIDだけを使用することに限定されず、表示名(ほとんど変更されません)を含めて、おそらくユーザーオブジェクト全体を含む多くの読み取りを排除します。

+0

詳細な回答ありがとうございます。あなたは、どんな種類のモデルが、TwitterやFacebookなどのソーシャルジャイアントで使用されているのか考えていますか?例えば、私がtwitter APIドキュメントをチェックすると、ほとんどのAPI関数はIDなしで "ドキュメント"を返します。これは、実行時にidを実際の "関連ドキュメント(オブジェクト)"に置き換え、jsonに変換した後にユーザーに返すということですか?あるいは、ドキュメントに実際の「関連オブジェクト」を格納していて、パワフルなサーバーで遅い/複雑な書き込みなどの問題を解決していますか?ありがとうございました! –

+0

apiのようなものは、基盤となる構造にはあまり関係ありません。大規模な公開APIの場合は、公開する必要のないデータを公開する必要はありません。巨人は、実際にはきれいなアーキテクチャを実際に探し出す最良の場所ではありません。数年のコードを更新することからくる複雑な問題はすべてあります。また、キャッシュと最適化のトンネルを持つmysqlのコアを持っていると思います最初から開始する場合はスタンドアロンで使用できるnosqlコンポーネント。 –

+0

したがって、文書内に関係のためのIDまたは一部の識別子フィールドを入れることは許容されます。 idを実際のオブジェクト値に置き換えるために何か追加作業をすることについてどう思いますか?私は、実行時に置換を検出するためにいくつかのカスタム属性を置かなければならないと思います... –

関連する問題