0

アプリケーションでデータ モデル (mongodb) を構築する最善の方法についてアドバイスを得るためにここにいます。

これらのエンティティがあるとしましょう:

ユーザー: すべての通常の属性を持つユーザーで、各ユーザーにフォロワーとフォローのリストが必要です。各ユーザーには、興味深いと思う「投稿」のリストもあります。

投稿: 投稿には、コンテンツ、作成日、作成者 (ユーザー)、投稿が好きなユーザーのリスト (投稿からユーザー情報を取得できるようにしたい)、コメントのリスト (コメント)

コメント: コメントには作成者 (ユーザー) とコンテンツがあり、投稿にリンクする必要があります。

私はこのアプリケーションが多くのコンテンツとユーザーを処理することを考えています。そのため、私はこのデータ モデルに非常に関心があり、保守性とパフォーマンスの観点から最善の方法で構築できるようにしたいと考えています。

埋め込まれたドキュメント機能を使用する必要があるか、リレーショナルのようなデータ モデルを再現する必要があるかを、自分で決めることはできません。

このデータモデルをどのように構築しますか?

4

1 に答える 1

1

投稿を MySQL から MongoDB に移行する過程にあるため、これらと同じことを検討しました。

ユーザーと投稿を別々のコレクションに保持し、それぞれに関心のあるプロパティのみを埋め込むことにしました。たとえば、投稿にはその投稿が好きなユーザーの配列がありますが、配列の各要素にはユーザーの名前とユーザー名しかありません。投稿を表示するときに、投稿が好きなユーザーの名前のリストを表示し、ユーザー名を使用して各ユーザーへのリンクを生成できます。

考慮する必要があるのは、ユーザーが自分の名前またはユーザー名を変更した場合、そのユーザーが作成または気に入ったすべての投稿を更新する必要があるということです。ユーザー名を変更することは許可されていません。この場合、名前を更新する必要はないと判断しました。

このアプローチのパフォーマンスに関する問題は、MongoDB がドキュメントを拡大できるようにドキュメントに自動的に追加するパディングと、割り当てられたこのスペースを超えてドキュメントが拡大した場合にドキュメントを移動するオーバーヘッドです。私たちのシステムは、フィード投稿の書き込みよりも読み取りの方がはるかに重いため、喜んで対処します。

MongoDB でスキーマを設計する正しい方法は、最終的にはデータへのアクセス方法と特定のユース ケースによって異なります。私たちもまだ始まったばかりですが、このアプローチは今のところ私たちにとって理にかなっています。

于 2013-10-10T09:11:52.670 に答える