CODEWITHSUNDEEP
mongodbschemameteor
songololo
songololo

Reputation: 4954

MongoDB schema structure and queries

I am using the meteor implementation of mongoDB and currently have a schema structured as such:

{
 photoalbum 1:
    {
     description: album,
     title: xyz,
     photos:
        {
         photo 1:
            {
             description: photo,
             photodata:
                {
                 title:xyz,
                 url:...,
                 tags:xyz
                }
            },
         photo 2:
            {....},
         photo 3:
            {....},
        }
    },
 photoalbum 2:
    {
     description: album,
     title: xyz,
     photos:
        {
         photo 1:
            {....},
         photo 2:
            {....},
         photo 3:
            {....},        
        }
    }
}

What I am effectively trying to do is to nest an array / object of photos inside their parent albums. My logic for doing this is that I'd like to be able to return all photos from a particular set and it seems intuitive to keep related photos nested together.

My question boils down to:

1) Is this schema design OK - or is it getting too nested and complex? For example, should I just leave the photos mixed in with the the sets in the top level of the collection?

2) How do I structure the database.find() operation to return only photos that belong to a certain set? I thought I'd be able to search for a particular type of item (e.g. {description:"photo"} within a certain parent level (e.g. {description:"album"} but I haven't figured out how this would actually work. Do I have to embed an album identifier in each photo and then query photos that match that identifier?

3) When is it better to use an array vs. an object - for example, my photolist is current an object, should this rather be an array?

Thanks.

Upvotes: 1

Views: 623

Answers (1)

vinipsmaker
vinipsmaker

Reputation: 2397

1)

Is this schema design OK - or is it getting too nested and complex?

This design requires you to know the photos key in advance, if you plan to do any operation to these keys. If this is okay to you, this design might work.

Other options would be:

  • Use an array of photos instead of an object photos.
  • Use a separate collection instead of embeding.

Indeed, schema design depends on your data, but, also important is what you plan to do with that data. The what is also important to the schema design.

For example, should I just leave the photos mixed in with the the sets in the top level of the collection?

Don't.

2)

How do I structure the database.find() operation to return only photos that belong to a certain set? I thought I'd be able to search for a particular type of item (e.g. {description:"photo"} within a certain parent level (e.g. {description:"album"} but I haven't figured out how this would actually work. Do I have to embed an album identifier in each photo and then query photos that match that identifier?

If you use an embeded document/array

Your query might look like this:

db.album.find({_id: 0/*album id*/})

And if you use arrays instead of objects, you can even query based on the photo's fields (you can read more about this here and here):

db.album.find({_id: 0/*album id*/, "photos.description": "hi there"})

If you se a separate collection for photos

You need to put the info about the containing album somewhere. If you put this info in the album collection, you'll need two queries. But, if you put this info in the photos collection, your query might look like:

db.photos.find({parentAlbum: 0/*album id*/})

3)

When is it better to use an array vs. an object - for example, my photolist is current an object, should this rather be an array?

If you can use an array without any problems, I'd recommend you that way, because you'll have richer expressiveness.

It might be problematic if you need a reference to an individual element of the array (see this).

PS.:

This is a confusing question. I'm not sure if I was able to answer what you asked for.

Upvotes: 1

Related Questions