1

私はまだモンゴのようなものが野生でどのように使われるかについて頭を包み込もうとしています。

誰かが私にこれを説明してもらえますか（私はそれが本当に簡単であることを知っています）？

さて、私がたくさんのサービスを持っているユーザーのセットを持っているとしましょう。SQLデータベースでは、それらは次のように保存されます。

ユーザーテーブル

| user_id | name | address |
|---------|------|---------|
| 1       | Zen  | 1 a St  |
|---------|------|---------|

サービス

| service_id | user_id | service_type | cost |
|------------|---------|--------------|------|
| 1          | 1       | hosting      | 50   |
|------------|---------|--------------|------|

Mongoでは、これをユーザー内に保存しますか？つまり、オブジェクトを使ったプログラミングを表現するようなものですか？

例えば

User: 1
    Name: Zen
    Address: 1 a St
    Services:
        service 1
             type: hosting
             cost: 50

もしそうなら、価値のある「ポインタ」を持つことはありますか（複数の「もの」が他の「もの」を「所有」する可能性がある状況、またはデータの階層にこれを必要とする関係がある場合）。

SQLのバックグラウンドから来て、Mongoを念頭に置いてこの問題にどのようにアプローチしますか？

ありがとう

4

3 に答える 3

1

モデリングは多かれ少なかれ抽象的です。SQL の世界では、テーブルは使用できる抽象化の最低レベルにすぎず、データを基礎となる主題に結び付けます。より高いレベルの抽象化は、リレーショナル モデリングと ER モデリングです。「より高い」は「より良い」の合言葉ではありません。抽象化の各レベルは、他の機能を覆い隠すことによって特定の機能を強調します。どのレベルが目的に役立つかは、何をより明確に見ようとしているかによって異なります。

他の回答の 1 つは、Mongo がネストをサポートしていることに言及しています。ネストは、多くの上部構造を課すことなく、データ項目間の階層関係をエンコードする方法です。しかし、Mongo を知らなければ、Mongo のアーキテクトがユーザーにネストを提供した理由がそれであるかどうかはわかりません。

階層関係は、何をしようとしているのかによって、役に立ったり邪魔になったりします。たとえば、ユーザーを知っていて、すべてのサービスを見つけようとしている場合、提案されたネスト構造は非常に使いやすく、おそらく非常に効率的です。しかし、サービスのことを知っていて、すべてのユーザーを見つけたいと思うなら、あなたは傷だらけの世界にいます。

階層構造の不幸な副作用を克服したことが、リレーショナル モデルとリレーショナル データベースが受け入れられた主な理由の 1 つです。しかし、上下関係が常に「悪い」とは限りません。場合によっては、これがデータをモデル化する最良の方法です。

質問に戻ると、テーブルをネスト構造と比較するよりも、より高いレベルの抽象化で SQL と Mongo を比較したい場合があります。SQL に関連して、より高いレベルの抽象化を探す必要があることを説明しました。他のレスポンダーは、Mongo についても同じことを言わなければなりません。

最終的に、抽象化のレベルを上げ続けると、SQL と Mongo の両方に等しく適したモデルが見つかるはずです。

于 2012-09-21T11:59:20.220 に答える
0

MongoDB での効果的なデータ モデリングは、アプリの要件と一般的なユース ケースに従います。ドキュメントは、シリアル化されたオブジェクトに似ていると考えることができます。MongoDB ドキュメント形式は、ネストを含む豊富なデータ構造を可能にします。

理想的なデータのクエリと操作方法を計画するために、アプリケーションのユースケースを最初に検討することは建設的です。MongoDB でスキーマを事前に宣言する必要がないため、プロトタイピングに役立ちます。多くの場合、MongoDB のスキーマは、結合を回避してパフォーマンスを向上させるために一部のデータが意図的に非正規化されるデータ ウェアハウスに似ています。実際、MongoDB は結合やサブクエリをサポートしていません :)。

リレーションシップについては、Object-Document Model または Data Mapper を使用している場合、いくつかの考慮事項もあります。リレーションシップ用のこれらのプロバイダー ヘルパーの多く。

従来の選択は、関連データを埋め込むかリンクするかです。

あなたの例では、usersコレクションとコレクションを持つことができますservices：

  • ユーザーが多数のサービスを持っている場合、サービスのリストをユーザー ドキュメント内の配列として埋め込む可能性があります。

  • ユーザーのサービスには、サービス ID や名前などの基本的な詳細が含まれる場合があります。serviceID は、サービス コレクション内の完全なサービス定義を検索するために使用できる一意の ID になります。これは、サービス コレクションにリンクしています。MongoDB サーバーは結合をサポートしていないため、ユーザーと各サービスの完全な詳細を検索する場合、複数のクエリが必要になることに注意してください。

関連読書:

于 2012-09-21T06:16:03.997 に答える
0

注: Mongo を使用したことはありませんが、いくつかの NoSQL ソリューションを使用して開発しました。

Redis と CouchDB の両方で、接頭辞スタイルの命名規則でオブジェクトを保存します。

Services ===
services.userid.1
services.userid.2

Users ===
users.userid.1
users.userid.2 ユーザー

のサービスを見つけるのは簡単です。=> services.user-name.wild-card

于 2012-09-21T01:42:41.023 に答える