[shingen]

It's amazing how when you focus on proven (but supposedly boring or old) technology that just works, and works very well, you can devote a lot of other resources to the actual product and usability.

Maybe it's the 30 year old in me showing, but I'm sticking with the 'it just works' crowd. Until some other approach provides a staggeringly overwhelming reason to switch. I find scaling up with MySQL to be ridiculously easy, allowing me to focus my time elsewhere. Ram, bandwidth, and fast storage have gotten substantially cheaper in the last few years, making it that much easier and cost effective to throw hardware at scaling up. For 99.9% of the Web, those hardware resources are expanding in value much faster than traffic is increasing.

(It's understood other developers find it just as easy to take a different approach)

[luigi]

It's amazing how when you use recent technology that has been designed and engineered from the ground up for the demands of modern web apps, you can devote a lot of other resources to the actual product and usability.

[geophile]

Modern web apps are applications. Applications, over time, run into many problems that SQL database systems were designed to address:

* The occasional join.

* Complex queries.

* Reporting.

* Schema changes.

* Transactions, with options for trading off strictness and performance.

* Performance problems that are easily addressed using stored procedures.

* Performance tuning with minimal code changes (e.g. adding an index to change the execution plan of a complex query).

* Enforcement of invariants regardless of application code.

Why would you give these up for scalability problems you won't have, with 99.999999% probability?

[gizzlon]

"Why would you give these up for scalability problems you won't have, with 99.999999% probability?"

I'm not saying people shouldn't use RDBMS', but there are many reasons for using something else:

  - The new databases/stores have different features and use cases. Many include features RDBMS' do not have.
  - Having to use table/column's for everything can be quite unnatural and tiresome.
  - RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds.
  - At least for me, using & learning something new is a big motivation booster :)

Use whatever is right for the job. But one should at least have a general knowledge of whats out there: features, pros & cons etc..

[geophile]

"The new databases/stores have different features and use cases. Many include features RDBMS' do not have."

True. My view is that the tradeoff comes out overwhelmingly on the RDBMS side most of the time.

"Having to use table/column's for everything can be quite unnatural and tiresome."

Unnatural in the sense that it is different from the first language you learn, yes. What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation.

"RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds."

I really think you need to learn something about RDBMS fundamentals. Set theory certainly "holds" to this day, and is certainly not legacy. The relational model is clumsy for some kinds of data ( (e.g. time series), but saying that the foundation is obsolete is just objectively false.

"At least for me, using & learning something new is a big motivation booster"

No argument there. But now take the next step and do an objective comparison between old and new. I have no problem with NoSQL systems. I even built one. But for nearly all applications, when you account for a wide set of requirements, (not just what is needed to get the MVP up and running), I think an RDBMS is the right tool.

[gizzlon]

"What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation"

Again, that depends on what you are doing. Converting back and forth between rows/tables and, say, data stored in hashes, is tiresome. It's also unnatural when the data doesn't "fit" in the relational model. Of course it works, but writing all this banal sql is not fun.

"I really think you need to learn something about RDBMS fundamentals...."

Right.. I was talking about the software. Maybe "models" is the wrong word.

"But now take the next step and do an objective comparison between old and new"

Believe it's pretty objective already.

[gaius]

The funny thing is hierarchical databases were all the rage in the 1960s (IBM's IMS for example) and the world moved on to the RDBMS.

I chuckle to myself when kids who wouldn't know a "legacy" app if it jumped up and bit them on the nose, go through the same thought process over and over again.

[route66]

Is it possible that

a) not all code written is for web apps

b) that said recent technology also only fits a niche for modern web apps?

I think you view on what constitutes modern web apps or software in general is biased in favor of some examples who benefit by using mongo/couch/redis whatever. (And are very vocal about it)

[EDIT: spelling, and to add that I have tremendous joy in playing with couch, redis, node lately. But at the same time I try to stay critical: what are the real trade offs when I employ these tools?]

[gaius]

the demands of modern web apps

Hmm, let's see. What does a "modern web app" do? Well there is a screen with fields for users to enter something, and there is another screen where things that (other) users have previously entered formatted nicely for display. Behind the scenes, this data is exchanged between machines that do some other processing on it.

They were doing this in the '60s.

[true_religion]

Er... you seem to be implying that people are using NoSQL solutions like Redis, Toyko Tyrant, Elastic Search, etc. for fun but that's not the case.

Sometimes you just pick the simplest thing that works and that can be a key value store, data structures in memory, or a lucrene interface. It's a better solution and less fragile than trying to force everything into a relational model.

[brazzy]

No, I think he's implying that people are using NoSQL solutions because they've been hyped a lot and are fashionable. And that's most certainly the case (certainly not the only reason in all cases, but most certainly a reason in many cases).

[robinwarren]

I must admit that I picked mongodb (+ node) for my latest project for fun. But I then discovered that being able to dump json straight into a datastore without having to create tables etc. first was a great benefit in quickly building something out.

So something I did for fun turned out to be the simplest thing which worked. Only I didn't know that when I did it. I think developers who don't occasionally pick something new for fun on a side project are doomed not to know when that new thing could actually be applicable on a project that matters.

[true_religion]

MongoDB isn't the best example to use as a genralization of NoSQL.

Many NoSQL databases have a structure you have to conform to---its just not a relational structure.

[karolist]

I'd actually like to do that too but have a hard time wrapping my head around the notion of building a website with node + nosql alone. My understanding is that node is best for realtime chat-like apps.. Is your project web related might I ask?

[grannyg00se]

Node is very handy for high transaction, short transfer, high connection count applications like chat. That's because of the non blocking single thread architecture, low overhead connections, and little bloat (small footprint).

However, that doesn't mean it isn't well suited for building a website. You'd probably want to include some add-ons for that though (eg: express).

Note that even for realtime chat-like apps you'll probably need some kind of datastore and in fact that example sounds like a great use case for nosql as a datastore.

[karolist]

Thank you for mentioning express, I'm now excited to use it in my next project!

[robinwarren]

Hi, sorry for the slow reply. As mentioned express is a good way to go for getting a website up with node.

Since you asked, my project is over here http://jobstractor.com if you want to take a look. My email is on the site so feel free to drop me a line if you have any questions. I'm planning on writing up my experience and a bit about how I've structured things so some questions might help me think through that.