Any thoughts on Amazon's DynamoDb while we all are fresh on Mongo discussion here? Thanks.
Think before you Mongo
21–30 of 101 posts
Re: Think before you Mongo
#22like 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.
NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster.
There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only.
Re: Think before you Mongo
#23If we treat schemaless is to Mongo then we are sure to abuse it after sometime. There are several other factors to consider. Mongo is NoSQL db and not a greek god of data storage. So, do not curse it for your sins.
Re: Think before you Mongo
#24like 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.
"NoSQL is simply the result of not wanting to think about the logical structure of data."
NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. Key value stores scale great, at the cost of having almost no query capabilities to speak of.
Now, some developers may adopt NoSQL due to the ease of getting a new project started. But I don't think that was the main motivation of the developers of the major NoSQL databases.
(Although, NoSQL is so broad I'm sure there are counter examples.)
Re: Think before you Mongo
#25Re: Think before you Mongo
#26I 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.
AFAIK quite a few businesses are stuck with it, as the cost of migrating to anything else would be prohibitive. It's usually easy to migrate logic from one language to another, it's harder to change a persistance layer, especially when it involves a paradigm shift such as NoSQL to SQL .
Re: Think before you Mongo
#27Earlier quoted context omitted.
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.
"NoSQL is simply the result of not wanting to think about the logical structure of data." NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. Key value stores scale great, at the cost of having almost no query capabilities to speak of. Now, some developers may adopt NoSQL due to the ease of getting a new project started. But I don't think that was the main motivation of the…
> NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model.
You can give up global consistency without sacrificing local (single-node) consistency. And normalization isn't an all-or-nothing proposition: you can select the kind of schema that best fits your needs. Unlike the case with NoSQL, which just says “lalala... I can't hear you” whenever you bring up consistency.
> Key value stores scale great, at the cost of having almost no query capabilities to speak of.
Far more worrisome is the loss of data integrity guarantees. It's okay to let me selectively disable these guarantees when I don't need them (say, by using a less structured schema), but a “database management system” that doesn't let me enforce the intended structure of my data, under any configuration, is simply not worthy of the name “database management system”.
Re: Think before you Mongo
#28Earlier quoted context omitted.
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.
NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical…
> Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster.
The CAP theorem doesn't force you to give up consistency within a single node. NoSQL databases often do, though.
> All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only.
So, instead of fixing programming languages, let's cripple databases?
Re: Think before you Mongo
#29Think before you Nodejs.
Please elaborate. This comment provides little to the discussion.
Not nodejs, but I am in the process of tracking down and event loop loop (e.g. emit( event_id ) somewhere in the path of an event lisener of that name). I assume this can happen within node too.
The stack trace is amazing to see.
Re: Think before you Mongo
#30Is it that time of the year, when mongo-hating blogs start popping up like daisies?
[deleted]