CODEWITHSUNDEEP
mongodbdatabase-schemadata-modeling
wandermonk
wandermonk

Reputation: 7386

MongoDB one to many design challenges with nested documents

What would be the best way to design schema for a User Settings REST api on top of mongodb.

I am from a Relational background. The problem is to transe a Relational data model to document or nosql data model.

The Use cases which my api's should serve is as below:

  1. Create a setting for a user
  2. Update a setting for a user
  3. read a setting for user
  4. delete a setting for a user

A User can be associated with multiple Applications. Each Application can have multiple Settings. I have read about one to many relationship from the mongodb documentation but did not get the feel of how to design.

The current designs i am considering are as below

Design 1:

User Document:

{
  "userid":"r8142r",
  "usertype":"admin",
  "applications":[application1Reference,application2Reference....]
}

Application Document:

{
  "applicationid":"application1Reference",
  "applicationSettings":[settings1Reference,settings2Reference...]
}

Settings Document:

{
  "settingid":"setting1Reference",
   "settingkey":"refreshTime",
   "settingValue":"20mins",
   "isActive":"yes",
   "updatedOn":"2017-06-22"
}

Design 2:

{
  "userid":"12345",
  "applicationID":[app1Ref,app2Ref],
  "settingKey":"refreshInterval",
  "settingValue":"20min",
  "groupName":"xgroup",
  "isActive":"yes",
  "uploadedOn":"2017-06-22"
}

The Design 1 looks like more of a relational way of design. The second design looks like a makeshift design because it does not serve my use cases.Is there any other way to design the documents.

I would like to know if this is the scale-able design. Can my DB Design cater to all usecases. What can be the issues.

Upvotes: 0

Views: 489

Answers (1)

Ra Ka
Ra Ka

Reputation: 3055

When I first jump in to no-sql database, I faced similar issue. I always try to design more relational schemas. But if you want to have full benefit of no-sql database, your design should be more document oriented, i.e. documents need to be saved hierarchically and all the required data needs to be stored in single document instead of multiple document or storing them in different tables with referential constraints as in SQL. That is why MongoDB does not support any joins or foreign key constraints or transaction. Also, this make MongoDB more scalable.

According to your use-case requirements, since each user can have multiple applications and each application may have multiple settings, and User -> Application -> Settings have one -> many relationship, you can embedded each application settings data to user document as below:

{
    //.. personal details
    "applications": [
        {
            "app_id":"12345",
            "name":"application_1",
            "settings": [
                {
                    "settingid":"1",
                    "settingkey":"refreshTime",
                    "settingValue":"20mins",
                    "isActive":"yes",
                    "updatedOn":"2017-06-22"
                },
                {
                    "settingid":"2",
                    "settingkey":"refreshTime",
                    "settingValue":"10mins",
                    "isActive":"no",
                    "updatedOn":"2017-06-22"
                }
            ]
        },
        {
            "app_id":"8999",
            "name":"application_12",
            "settings": [
                {
                    "settingid":"1",
                    "settingkey":"refreshTime",
                    "settingValue":"20mins",
                    "isActive":"yes",
                    "updatedOn":"2017-06-22"
                }
            ]
        }
    ]
}

Upvotes: 1

Related Questions