[intinig]

Tichy, give it a spin. The ease of execution (and the sheer speed, even over giant amounts of data) is impressive.

[dagheti]

What do you mean by impressive "ease of execution"?

How terse the code is? How easy the code is to read? How likely the code is to be correct? How flexible the data model is to new requirements? How simply you can reason about what the code does?

[intinig]

The code is easy to read, and the data model is as flexible as you want it to be, since it's schemaless.

Reasoning about what the code does is simple once you shift your paradigm to document from relational.

[old-gregg]

Do your research. "document-based" DBs already "ruled the world" right until relational databases were invented, which quickly obsoleted them.

The only advantage of disk-backed hash table is ease of scalability, this is why they're useful for hm.... top 0.005% of web sites, who handle thousands of updates per second.

[jshen]

They are also useful for rapid app development or prototyping. I've used couchdb this way a few times and it works great.

[sounddust]

I simply don't believe that this model scales "over giant amounts of data", at least in any sort of real-world usage scenario. Can you back up this claim with benchmarks?

[Tichy]

Reading CouchDB documentation now and can't stop reading. It sounds like a lot of fun. Haven't understood yet how to handle the performance problems, but would like to use it just for the fun of it.

[Tichy]

I can imagine some benefits, but as for speed of execution I am really doubtful. Your example suggests a "select all" followed by some analysis done in code. I can't imagine this scales well.

[jshen]

It creates an index for each view essentially. It's not anything like a "select all".