6

そうですね、Node.js を使って自分のウェブサイトのブログを書き始めようとしています (学習プロセスと同じくらい)。

あちこち検索すると、「Mongo でブログを書く方法」ガイドがいくつか作成されましたが、私が直面しているような問題はカバーされていないようです。ここに私のジレンマがあります：

MySQLを使用する場合、スキーマは次のようなものであると想像できます。

投稿:

ID, USER, DATE, TITLE, TAGS

コメント:

POST_ID, USER, DATE, MESSAGE

ユーザー:

ID, SCREEN_NAME, IMAGE_URL

したがって、各投稿にはコメントが関連付けられており、投稿とコメントにはユーザーが関連付けられています。利点は、ユーザーが自分のスクリーン名または画像を変更したい場合、users テーブルの 1 行だけを更新する必要があることです。ただし、おそらく複数の潜在的なタグに対して複数のフィールドがない限り、Xタグを含むすべての投稿を取得する方法はわかりません。

または、 MongoDBのようなものを使用して、次のようにフォーマットすることを検討していました。

投稿コレクション:

{ 
    {
    _ID: something
    USER: {id: id, name: "screen name", image: "image_url"}
    DATE: ...
    TITLE: ...
    TAGS: [tag1, tag2...]
    COMMENTS: 
         [
         {USER:someone, DATE:something, MESSAGE:"hi"},
         {USER:someone, DATE:something, MESSAGE:"another message"}
         ]
    },
    {
    _ID: something,
    USER: {id: id, name: "screen name", image: "image_url"},
    DATE: ...
    TITLE: ...
    TAGS: [tag1, tag2...]
    COMMENTS: 
         [
         ...
         ]
    },
}

そのため、各投稿にコメントが埋め込まれているのは当然のことです。

ここでは、1 つのクエリで、一致するすべての投稿を取得できます。これはすばらしいことです。一方で、ユーザーが使用するスクリーン名や画像を更新する必要がある場合はどうすればよいでしょうか? すべての投稿で関連するすべてのレコードを更新することは言うまでもなく、特定のドキュメント内の埋め込みオブジェクトを掘り下げるのは難しいようです。

コメントを別のコレクションに移動してアクセスしやすくすることもできますが、それでも、スクリーン ネームなどに関する多くの更新を行う必要があります。

そう...

本質的に、私は MongoDB を使用することを好みます。MongoDB でできること、非常に簡単にできること、および 1 つの言語で全面的に作業できることは素晴らしいことです。しかし、物事を「適切に」行うには、リレーショナルなアプローチを採用する必要があると感じずにはいられません。

どちらか、または両方の言語で似たようなことをした経験のある人はいますか?

これについてどう思いますか?具体的には、ユーザーとコメント/投稿との関係をどのように処理していますか?

事前に助けてくれてありがとう:)ジェームズ

4

3 に答える 3

7

MongoDB と SQL の両方がこのような小さなデータセットをまったく同じ方法で選択するため、実際に測定可能なパフォーマンスの向上はありません。

このような状況での MongoDB の主なアイデアは、多くのテーブルを 1 つのテーブル内にネストできるため、情報を更新するためのクエリを減らすことができるということです。それだけでなく、実際にデータを使用する方法に対してスキーマの方が自然な場合もあります。

スキーマのいくつかを変更します。

USER: {id: id, name: "screen name", image: "image_url"}

これはObjectId、ユーザー行に関連するものであり、コメントでも同様です。

{USER:someone, DATE:something, MESSAGE:"hi"}

フィールドに を使用ObjectIdしUSERます。これらObjectIdの は、ユーザー コレクションに関連します。また、それらの大文字を取り出してください。コーディングするのが面倒になると思います。

リレーションの処理については、繰り返し可能な情報をサブドキュメントとしてエンティティにネストします (通常は 1 番目の NF で正規化されます)。ただし、無限にネストする必要があるわけではありません。通常、互換性のクエリには最大 3 レベルが推奨されます。blog、 、postなどのアプリ エンティティの境界を念頭に置いてuserください。

blogここで、行などのネストされたリレーションを管理する必要はありませんuser(投稿にはコメントなどがネストされるため)。これらの関係を解決する方法は、クライアント側です。MongoDB にはリレーショナルの理想がないためです (これは RDB の異端者です)。

ユーザーと投稿の間の結合である各行の巨大な結果セットを選択するのではなく、ユーザーを個別に選択し、そのユーザー ID に基づいて投稿を選択するという、MySQL が通常サーバー側のクライアント側で行うことを単純に行うだけです。テーブル。

于 2012-10-17T21:38:57.637 に答える
0

物事を適切に行うためにリレーショナル アプローチが必要であることに同意しません。

この決定は、ACID とリレーショナル機能を省略できるかどうかにかかっています。

ブログがドキュメント ベースの場合は、おそらく NoSQL アプローチがうまく機能します。

さらに良いことに、Java や C# などのオブジェクト指向言語を使用している場合は、インターフェイスの背後にあるものを保持する方法の詳細を抽象化し、ある実装を別の実装に交換できます。そのようにロックする必要はありません。

于 2012-10-17T18:59:52.423 に答える
-6

私はワードプレスを使っていましたが、とても人気があり、パフォーマンスの問題は一度もありませんでした! 今日、世界中の Web サイトの 25% がワードプレスを使用しています。

于 2012-10-17T18:59:32.033 に答える