1

チーム間で共有されるOrgリソース（スキーマ）を含むコレクション（スキーマ）がありますResourcesTeams

{
   "_id": ObjectId("511cfbc9d593e5290c000005"),
   "name": "Some org name",
   "resources": [
       {
           "_id": ObjectId("511cfbc9d593e5290c000007"),
           "name": "Printer1",
           /* mongoose.Schema.Types.Mixed */
           "details": {
              "ip": "192.168.1.99"
           }
       }, {
           "_id": ObjectId("511cfbc9d593e5290c000008")
           "name": "Fax1",
           "details": {
               "number": "XXXXXXXXXXXX"
           }
       }
   ],
   "teams" : [
       {
            "_id": ObjectId("511cfbc9d593e5290c000012"),
            "name": "sales",
            /*"resources": {type: [mongoose.Schema.Types.ObjectId], ref: 'Resources'}*/
            "resources": [ObjectId("511cfbc9d593e5290c000007")]
       }, {
            "_id": ObjectId("511cfbc9d593e5290c000006"),
            "name": "developer",
            "resources": [ObjectId("511cfbc9d593e5290c000007"), ObjectId("511cfbc9d593e5290c000008")]
       }
   ]      
}

またPeople、チームの一部であるコレクションもあります。

{
    "name": "Peter",
    "designation": "senior s/w engg.",
    "contact": {}
    /*"teams": {type: [mongoose.Schema.Types.ObjectId], ref: 'Teams'}*/
    "teams": [ObjectId("511cfbc9d593e5290c000006")]
}

リソースまたはチームが変更された場合に複数の更新をスキップしたいので、ネストされたドキュメントは使用しませんでした。ref Resourcesスキーマからスキーマ化できませんTeams。その結果、次の結果を得るには、非常に複雑な集計関数を使用する必要があります。

{   
    "name": "Peter",
    "designation": "senior s/w engg.",
    "contact": {}
    "teams": [{
                "_id": ObjectId("511cfbc9d593e5290c000006"),
                "name": "developer",
                "resources": [{
                    "_id": ObjectId("511cfbc9d593e5290c000007"),
                    "name": "Printer1",
                    "details": {
                        "ip": "192.168.1.99"
                    }
                 }, {
                    "_id": ObjectId("511cfbc9d593e5290c000008")
                     "name": "Fax1",
                     "details": {
                         "number": "XXXXXXXXXXXX"
                    }
                 }]              
     }]
}

データベースの設計に何か問題があるかどうかを提案してください。もっと簡単な方法はありますか？

4

2 に答える 2

3

リソースまたはチームが変更された場合に複数の更新をスキップしたいので、ネストされたドキュメントは使用しませんでした。

これは、MongoDB スキーマ設計で考慮すべき一般的なトレードオフであることがわかります。実際には、複数の更新をスキップすることがどれほど重要かということになります。多くの場合、複数の更新は思ったほど難しくなく、特に読み取りのシンプルさとパフォーマンスが必要な場合は、正しい決定であることが判明します。

データベースの設計に何か問題があるかどうかを提案してください。もっと簡単な方法はありますか？

複数の更新を回避するというあなたの意図を考えると、あなたのアプローチに問題はないと思います。個人的には、この状況では、ネストされたドキュメントのアプローチを採用し、複数の更新を回避しようとします。これは、クエリがはるかに簡単になり、パフォーマンスも向上することを意味します (これは、多くの場合、アプリ開発で最も重要な考慮事項になる傾向があります)。

于 2013-02-18T19:43:37.083 に答える
0

マングースでは、次のように簡単に実行できます。

People.find({ name: "Peter" }).populate("teams").exec( callback );

これが人口をもたらさない場合teams.resources（マングースは非常に柔軟であるため、私は疑っています）、代わりにこれを試してください：

People.find({ name: "Peter" })
    .populate("teams")
    .populate("teams.resources")
    .exec( callback );

また、スキーマrefのteamsプロパティを追加することを忘れないでください。People

于 2013-02-18T15:54:46.537 に答える