Hacker News Reader

Comment by Harrisburg | Hacker News Reader

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.

View on HN

"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.

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.

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?).

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.

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.

In a sql db, every single thing needs to fit into a flat schema with nesting done by relations.

Nope, see Postgres (hstore and json).

why not "see sql server from 10 years ago with xml column type"?

Because one example is enough to dispel that myth, and I'm familiar with Postgres, and not with "sql server from 10 years ago with xml column type".

I would probably solve this problem using Relational DB by having an ItemHeader table with all the common attributes. Then will make an ItemAttributes table where I'd use the foreign key of the first table and just have Key/value pairs for all the unique attributes you want to give to the item. Any sort of query on any of the attributes can be one via a simple join.

Though i suppose it gets trickier if attributes may have sub attributes etc....

"In 2015, the Mongo backlash is just as tired as the Mongo hype."

If you say so.

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

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

Probably the EAV nightmare

Stick JSON in a field within your relational model - best of both worlds.

I wish I could have a foreignkey within that json.

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

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.

Joins are not supported by Mongo. Or at least, not in any way that isn't tortuous.

query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'})

@see: http://docs.mongodb.org/ecosystem/use-cases/product-catalog/

I personally miss Joins in MongoDB - but other vendors support Joins.

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

HA! You got him. A gold star for you sir.

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).

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.

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

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

Reply on news.ycombinator.com