6 ms·

Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: S

Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain for all products, others will vary, some will change and will be dropped. Some may be conditional, depending on size or color. I could model that in RDBMS as well, adding those properties in an additional JSON or something else. Yes, I'm also mainly using relational databases and just wanted to give an example of a use-case for MongoDB. I regret, sorry.

rjaco31 12y ago
Care to elaborate? Beside maybe for the suggestion system, I really don't see what's the gain compared to a relational database.
- BonoboBoner 12y ago
  Probably the EAV nightmare
  - arethuza 12y ago
    Stick JSON in a field within your relational model - best of both worlds.
    - BonoboBoner 12y ago
      I wish I could have a foreignkey within that json.
CmonDev 12y ago
You can always just stick JSON into a separate table for those cases. So that alone is not an argument.
collyw 12y ago
I wouldn't personally say it fits better. And you are throwing away a ton of useful features that come with a relational database.
crdoconnor 12y ago
So what happens when you want to list all of the products in a category?
- collyw 12y ago
  Have a category field or link in the table. Join to it. Joins are not evil, they are damn useful. And well done if your product has become large enough to have scaling problems that can't be solved by a bit of indexing on the joins.
  - crdoconnor 12y ago
    Joins are not supported by Mongo. Or at least, not in any way that isn't tortuous.
- Harrisburg 12y ago
  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).
ris 12y ago
"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.
- woah 12y ago
  Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting done by relations. Additionally, it's very rigid. Maybe you just don't want to set up a laces table, and 4000 other tables for every little attribute of every product. Of course this is not how you would do it in real life, there are better ways. Mongo is one of those ways. Saying that Mongo is good for nothing is just as dumb as saying that Mongo is good for everything. In 2015, the Mongo backlash is just as tired as the Mongo hype.
  - annnnd 12y ago
    Agreed. That said, optional schema enforcement would be really nice (in my experience, most of the data has a predefined format; so why not define schema and enforce it?).
  - gasping 12y ago
    Are you saying you're using a single MongoDB collection as a dumping ground for all your entities? I hope you're not building a real product that someone has to maintain.
  - woah 12y ago
    I don't actually use Mongo at all, I prefer Postgres. But for loosely structured data, it has a use case. Just like dynamic vs typed languages, there are pros and cons.
  - icebraining 12y ago
rimantas 12y ago
I'd say elasticsearch is often used for this kind of tasks.

rjaco31 12y ago

Care to elaborate? Beside maybe for the suggestion system, I really don't see what's the gain compared to a relational database.

BonoboBoner 12y ago
Probably the EAV nightmare
- arethuza 12y ago
  Stick JSON in a field within your relational model - best of both worlds.
  - BonoboBoner 12y ago
    I wish I could have a foreignkey within that json.

CmonDev 12y ago

You can always just stick JSON into a separate table for those cases. So that alone is not an argument.

collyw 12y ago

I wouldn't personally say it fits better. And you are throwing away a ton of useful features that come with a relational database.

crdoconnor 12y ago

So what happens when you want to list all of the products in a category?

collyw 12y ago
Have a category field or link in the table. Join to it. Joins are not evil, they are damn useful. And well done if your product has become large enough to have scaling problems that can't be solved by a bit of indexing on the joins.
- crdoconnor 12y ago
  Joins are not supported by Mongo. Or at least, not in any way that isn't tortuous.
Harrisburg 12y ago
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).

ris 12y ago

"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.

woah 12y ago
Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting done by relations. Additionally, it's very rigid. Maybe you just don't want to set up a laces table, and 4000 other tables for every little attribute of every product. Of course this is not how you would do it in real life, there are better ways. Mongo is one of those ways. Saying that Mongo is good for nothing is just as dumb as saying that Mongo is good for everything. In 2015, the Mongo backlash is just as tired as the Mongo hype.
- annnnd 12y ago
  Agreed. That said, optional schema enforcement would be really nice (in my experience, most of the data has a predefined format; so why not define schema and enforce it?).
- gasping 12y ago
  Are you saying you're using a single MongoDB collection as a dumping ground for all your entities? I hope you're not building a real product that someone has to maintain.
- woah 12y ago
  I don't actually use Mongo at all, I prefer Postgres. But for loosely structured data, it has a use case. Just like dynamic vs typed languages, there are pros and cons.
- icebraining 12y ago

rimantas 12y ago

I'd say elasticsearch is often used for this kind of tasks.