Many to many in MongoDB

I decided to give MongoDB a try and see how well we get along. I do have some questions though.

Premise

• I have users(id, name, address, password, email, etc)
• I have stamps(id, type, value, price, etc)
• Users browse through a stamp archive and filter it in various ways(pagination, filter by price, type, name, etc), select a stamp then add it to their collection.
• Users can add more then one stamp to their collection (1 piece of mint and one used or just 2 pieces of used)
• Users can flag some of their stamps for sale or trade and perhapa specify a price.

So far

Here's what I have so far:

{
 _id : objectid,
 Name: "bob",
 Email: "bob@bob.com",
 ...
 Stamps: [stampid-1, stampid-543,...,stampid-23]
}

Questions

1. How should I add the state of the owned stamp, the quantity and condition?
2. what would be some sample queries for the situations described earlier?
3. As far as I know, ensureindex makes it so you reduce th开发者_如何学Goe number of "scanned" entries.

The accepted answer here keeps changing the index. Is that just for the purpose of explaining it or is this the way to do it? I mean it does make sense somehow but I keep thinking of it in sql terms and... it does not make ANY sense...

---

The only change I would do is how you store the stamps that a user owns. I would store an array of objects representing the stamps and duplicating the values that are the more often accessed.

For example something like that :

{
    _id : objectid,
    Name: "bob",
    Email: "bob@bob.com",
    ...
    Stamps : [
        {
            _id: id,
            type: 'type',
            price: 20,
            forSale: true/false,
            quantity: 2
        },
        {
            _id: id2,
            type: 'type2',
            price: 5,
            forSale: false,
            quantity: 10
        }
    ]
}

You can see that some datas are duplicated between the stamps collection and the stamps array in the user collection. You do that with the properties that you access the more often. Because otherwise you would have to do a findOne for each stamps, and it is better to read directly the data that doing that in MongoDB. And this way you can add others properties such as quantity and forSale here.

The goal of duplication here is to avoid to run a query for each stamp in the array.

There is a link of a video that discusses MongoDB design and also explains what I tried to explain here.

http://lacantine.ubicast.eu/videos/3-mongodb-deployment-strategies/

---

from a SQL background, struggling with NoSQL also. It seems to me that a lot hinges on how unchanging types of data may or may not be. One thing that puzzles me in RDBMS systems is why it is not possible to say a particular column/field is "immutable". If you know a field is immutable (or nearly) in a NoSQL context it seems me to make it more acceptable to duplicate the info. Is it complete heresy to suggest that in many contexts you might actually want a combination of SQL and NoSQL structures?