0

I started my studies in MongoDB recently and I didn't understand much better how we make the relationship between the entities that we have in the system.

So, as I am used to make this relationships in the SQL way, I get kind of confused when I change the logic to think in NoSQL way.

I saw that MongoDB has to types of modeling: Embedded and Referenced.

If I understand correct, Referenced is like we do in SQL:

  • Example: 1-to-N

  • Create two tables to represent the entities, like User and Address.

  • Create an user object and an address object

  • Put the Address ID into an user object 

{
   "_id":ObjectId("52ffc33cd85242f436000001"),
   "contact": "987654321",
   "dob": "01-01-1991",
   "name": "Tom Benzamin",
   "address_ids": [
      ObjectId("52ffc4a5d85242602e000000"),
      ObjectId("52ffc4a5d85242602e000001")
   ]
}

And the Embedded:

  • Create just one table, in this case User.

  • Create an user object and inside of it put the address object:

{
   "_id":ObjectId("52ffc33cd85242f436000001"),
   "contact": "987654321",
   "dob": "01-01-1991",
   "name": "Tom Benzamin",
   "address": [
      {
         "building": "22 A, Indiana Apt",
         "pincode": 123456,
         "city": "Los Angeles",
         "state": "California"
      },
      {
         "building": "170 A, Acropolis Apt",
         "pincode": 456789,
         "city": "Chicago",
         "state": "Illinois"
      }]
}

So, my questions are:

To use the best features of a NoSQL Database like MongoDB, I have to use Embedded Modeling ?

In Embedded Modeling I just create only one Entity and the entity that is inside, the address object in this case, will not have an ID, since I didn't create a table ?

Community
  • 1
  • 1
Murilo
  • 4,453
  • 5
  • 19
  • 28
  • 1
    The easiest way to go about this is think about how the application will access this data. You'll want to put `address` inside `user`, if from the application when you retrieve an user, you want all of the associated address objects as well, thus eliminating the need for joins (which isn't supported in MongoDB). – Anand Jayabalan Sep 08 '14 at 14:13

1 Answers1

1

You're right with MongoDB. As you said, you have two ways to stock data. The best way depends on what you need.

If your address object is going to be used somewhere else, put it in another table, if not, you can put it directly in your object.

If you're using MongoDB with NodeJS, you can use MongooseJS. It's a kind of framework which has the particularity to define schemas for your mongodb objects. It works fine particulary with embedded objects because it add an objectId for every object you embed.

T00rk
  • 2,178
  • 3
  • 17
  • 23
  • I don't know anything about this NodeJS :/. I will look up for something about it. Just to confirm my knowledge: I use embedded modeling when the object that is embedeed will not appear in any other collection. So, in this case, Address is not a good example. Because I can use it in many other collections. Correct ? – Murilo Sep 08 '14 at 14:06
  • 1
    Sorry I'll put an example in another answer – T00rk Sep 08 '14 at 14:10
  • 1
    Sorry i didn't have the right to send comments since today. As I was saying yesterday, maybe the best way for your example is to split your address object like this http://pastebin.com/fKeeP2mD – T00rk Sep 09 '14 at 08:42