Live data from Hacker News

Think before you Mongo

blog.runnable.com

11–20 of 101 posts

Re: Think before you Mongo

#11
post #9

like the yesterday's submission of "Why you should never use MongoDB (2013)" ( https://news.ycombinator.com/item?id=12290739 ), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study h…

Right tool for the right job. Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet. There is room in the world for both.

Re: Think before you Mongo

#12
post #9

like the yesterday's submission of "Why you should never use MongoDB (2013)" ( https://news.ycombinator.com/item?id=12290739 ), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study h…

I am yet to fail into this NoSQL trend.

Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit.

Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.

Re: Think before you Mongo

#13

Earlier quoted context omitted.

But there are other databases that are good at that, too, and don't drop your data. RethinkDB? RavenDB? Depending on the type of data you're using either of those could be an option, and won't just drop your data randomly.

Yeah, drivers are not as good tho. That also counts, am I wrong?

The RethinkDB drivers are phenomenal in 4 to 5 languages.

Re: Think before you Mongo

#14

Earlier quoted context omitted.

But there are other databases that are good at that, too, and don't drop your data. RethinkDB? RavenDB? Depending on the type of data you're using either of those could be an option, and won't just drop your data randomly.

Yeah, drivers are not as good tho. That also counts, am I wrong?

I've had nothing but positive experience with RethinkDB drivers. RavenDB has good drivers for some languages, but admittedly not every language is well-supported.

Still, I can't see a situation where I would choose a non-working datastore over a working datastore.

Re: Think before you Mongo

#15
post #9

like the yesterday's submission of "Why you should never use MongoDB (2013)" ( https://news.ycombinator.com/item?id=12290739 ), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study h…

Right tool for the right job. Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet. There is room in the world for both.

but we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model.

if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single pre-designated root.

both relational and hierarchical databases let you go from department to employee, only one lets you go from employee to their department without enumeration. what purpose does precluding the latter serve?

Re: Think before you Mongo

#16
post #9

like the yesterday's submission of "Why you should never use MongoDB (2013)" ( https://news.ycombinator.com/item?id=12290739 ), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study h…

The relational model does have deficiencies, but the right way to address them is with more powerful schemas, not less. See: “categorical databases”.

(Think about it this way: SQL is Java. NoSQL is your typical extremely forgiving dynamic language. We need a database equivalent of ML and Haskell.)

NoSQL is simply the result of not wanting to think about the logical structure of data. Plain intellectual laziness.

Re: Think before you Mongo

#19

I agree... but at this point, it's tough to see with all the ink that's been spilled on these issues for years how you could think anything else. Maybe I read HN too much, but the manifold problems with MongoDB have been widely publicized for the past 6 years... it seems pretty close to conventional wisdom that you're going to have those problems if you decide to use Mongo.

Because Mongo is wrongly marketed as "all-in-one" database. Instead it should be marketed as "good database for dynamic data that requires complex filtering, also we have very good drivers for many languages" because that's the only thing it's good at.

I think it also might be okay as storage for dervied data, but then again, why not shove it into `uuid-jsonb` Postgres table, perhaps on the second server.

Re: Think before you Mongo

#20
post #9

like the yesterday's submission of "Why you should never use MongoDB (2013)" ( https://news.ycombinator.com/item?id=12290739 ), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study h…

The relational model does have deficiencies, but the right way to address them is with more powerful schemas, not less. See: “categorical databases”. (Think about it this way: SQL is Java. NoSQL is your typical extremely forgiving dynamic language. We need a database equivalent of ML and Haskell.) NoSQL is simply the result of not wanting to think about the logical structure of data. Plain intellectual laziness.

And the millennials dislike for not wanting to learn SQL, I think.

You always see how they bash having to learn SQL on those presentations.

Post reply on HN