4 ms·

query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}) @see: http://docs.mongodb.org/ecosystem/use-cases/product

query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}) @see: http://docs.mongodb.org/ecosystem/use-cases/product-catalog/ http://docs.mongodb.org/ecosystem/use-cases/product-catalog/ I personally miss Joins in MongoDB - but other vendors support Joins.

ris 12y ago
There - you're consistently using a field named "type" across your objects - you're using a schema.
- woah 12y ago
  HA! You got him. A gold star for you sir.
- onion2k 12y ago
  Not quite. The 'type' in the example is a label for what it contains - it's wholly semantic - as opposed to a field that would exert some sort of constraint such as describing the data type, collation, restraints, etc. Schemaless databases don't completely abandon all forms of organisation because that'd be unusable. They just make the organisation looser. For example, if the user wanted to they could add a record to the products in that example that doesn't have a 'type' (although in the case of that example that probably wouldn't be useful).
  - takeda 12y ago
    The thing is that in order to use that /label/ you need to write logic to handle it in your code, ultimately you end up implementing schema, the only difference is that you enforce it in your application. This label becomes not much different than a column in database that is nullable. Now things become more hairy when you realize that perhaps you want to keep more information about the actor so for example you want to change details.actor to details.actor.name. You will have two choices, either run through your database and modify all documents (which is something similar to RDBMS is doing) or write code to handle both cases. The second one seems easier, but as you'll have more changes it'll come back and bite you hard. Later in the future you might realize that by repeating details about actor for every single movie you simply not only wasting a lot of resources (your database is bigger and slower) but also this affects integrity (in one movie perhaps you include actor's middle name, or maybe you have a typo). At that point you'll start creating a collection that holds actors and then only store key of it in "details.actors". You will soon realize that you're basically reimplementing a relational database on top of Mongo, except not only it is way slower, your application is becoming more complex. There are uses for NoSQL, but whenever you have to ask yourself which model you should go with pretty much always the answer will be: relational.

ris 12y ago

There - you're consistently using a field named "type" across your objects - you're using a schema.

woah 12y ago
HA! You got him. A gold star for you sir.
onion2k 12y ago
Not quite. The 'type' in the example is a label for what it contains - it's wholly semantic - as opposed to a field that would exert some sort of constraint such as describing the data type, collation, restraints, etc. Schemaless databases don't completely abandon all forms of organisation because that'd be unusable. They just make the organisation looser. For example, if the user wanted to they could add a record to the products in that example that doesn't have a 'type' (although in the case of that example that probably wouldn't be useful).
- takeda 12y ago
  The thing is that in order to use that /label/ you need to write logic to handle it in your code, ultimately you end up implementing schema, the only difference is that you enforce it in your application. This label becomes not much different than a column in database that is nullable. Now things become more hairy when you realize that perhaps you want to keep more information about the actor so for example you want to change details.actor to details.actor.name. You will have two choices, either run through your database and modify all documents (which is something similar to RDBMS is doing) or write code to handle both cases. The second one seems easier, but as you'll have more changes it'll come back and bite you hard. Later in the future you might realize that by repeating details about actor for every single movie you simply not only wasting a lot of resources (your database is bigger and slower) but also this affects integrity (in one movie perhaps you include actor's middle name, or maybe you have a typo). At that point you'll start creating a collection that holds actors and then only store key of it in "details.actors". You will soon realize that you're basically reimplementing a relational database on top of Mongo, except not only it is way slower, your application is becoming more complex. There are uses for NoSQL, but whenever you have to ask yourself which model you should go with pretty much always the answer will be: relational.