Many to many Realm

MongoDB Realm
#1

Hi,

I want to generate a relations many to many between user and prizes with array but can’t figure it out, here the schema:

{
  "title": "user",
  "properties": {
    "_id": {
      "bsonType": "objectId"
    },
    "adress": {
      "bsonType": "object",
      "properties": {
        "city": {
          "bsonType": "string"
        },
        "zip_code": {
          "bsonType": "string"
        }
      }
    },
    "firstname": {
      "bsonType": "string"
    },
    "lastname": {
      "bsonType": "string"
    },
    "prize_id": {
      "bsonType": "objectId"
    },
    "prizes": {
      "bsonType": "array",
      "items": {
        "bsonType": "object",
        "properties": {
          "is_favorite": {
            "bsonType": "bool"
          },
          "prize_id": {
            "bsonType": "objectId"
          }
        }
      }
    }
  }
}

{
“title”: “prize”,
“properties”: {
“_id”: {
“bsonType”: “objectId”
},
“title”: {
“bsonType”: “string”
}
}
}

Found nothing on the documentation, thank you for your help.

#2

Hello @Nabil_Ben

Generally data modelling is a broad topic to discuss, this is due to many factors that may affect the design decision. One major factor is the application requirements, knowing how the application is going to interact with the database. With MongoDB flexible schema characteristic, developers can focus on the application design and let the database design conform for the benefit of the application. See also :

You may also can checkout:

A very good start is a the MongoDB University Class: M320 Data Modeling . There is an entire chapter on M:N relations and the various options to design them.

Regards,
Michael

#3

Thank you, it’s not quite what i’m looking for but i found a way by creating an array of ObjectID in a join table.

It’s the only way i found to make a many to many relationships with attributes depending on this relation.
I’m generating a graphQL API from this.

join

#4

Hello @Nabil_Ben

solutions depend on the specific use case and how you access the data. In case your use cases are “user driven” you may want to embed the prizes. This would be sense full when this is a point in time information, e.g. an order is shipped to a certain address. In case the user moves the address in the order will stay the same. Embedding even makes sense when you have one side of your many sides which is only rarely changing . You gain performance but you have to pay with updating duplication, this again can be done in an off peak time, in case you can accept some hours of stale data.
An other pattern could be the subset pattern, here you keep the latest x records as duplicates, e.g. last ordered items, you’d get the last lets say 10 very quick since they are embedded, if you want to see more than you need to do further reading in a second collection. The cost is again on maintaining the duplication. Again this can be done in off peak time or just with a longer lasting update. You get the idea? (you do not need to keep the data duplicated, you also can spread them in the subset, embedded and the majority in a further collection. If you do this you need to keep this in mind when you access the data on the second collection)
Just step on step back, analyze the workload and access queries and than go for a pattern. $lookup as a subset of an “join” should be the very last resort.

Regards
Michael

1 Like