The more of these "software hipsters" that fail to understand CouchDB and quickly abandon it, the better. Wish I had more to say about this article, but that's about it.
edit: in case it's not clear, I like couchdb a lot and I think it's absurd that people people are backlashing against it because some monkey coder dorks found it highly buzzword compliant and are making it popular, despite not understanding it at all. So you end up with people hating something because it's getting some limelight for whatever reason, and then also many of the people championing it don't know how to use it correctly to build an app or anything. It's like two layers of stupid.
Software hipsters are the ones using CouchDB. The relational model has been refined over decades to accommodate the requirements of generic information systems and eliminate a lot of the problems that mapreduce-based databases ignore.
CouchDB solves a subset of information problems. The relational model can solve a vastly greater amount of problems.
What? CouchDB gets a lot of hype. Naturally people are curious, and they try to use it to solve their problems. Sometimes these problems aren't the problems CouchDB is good for. You can't fault the "software hipsters"--- the CouchDB documentation does a terrible job of explaining the "Why" of CouchDB.
"software hipster" is an inaccurate characterization. Hipsters tend to choose something because it is simple and stylish rather than actually useful. As an example, they like fixed gear bikes.
Unfortunately, simple and stylish doesn't always win. I see lots of people riding fixed gear bikes in Seattle, for example. Actually, I don't see many people riding them, I see them walking them around because they have the wrong gearing for going up and down Seattle's many hills, and they can't actually ride them. In this case, simple and stylish is the wrong tool for the job -- they need a bike that can change gears. That may be inelegant, but it works really well.
CouchDB is the fixed gear bicycle of the database world.
Discussions about CouchDB focus on its very large and complicated featureset. It would be interesting to see examples of actual problems it's good for and why or how it worked for them. I've seen one example where it wasn't very good and the developer switched to an SQL database, but nothing beyond that. Their website doesn't have anything like this, sadly.
Unfortunately you can only create a view from the
original data, there is no way to create views whose
input is other views. This means that you cannot do
anything really interesting with values from multiple
documents. You can aggregate data from several documents
using the reduce functionality into buckets, but you
can't process that data further.
I've come to this idea also - when we do get it the world changes. New era for hackers. We will be able to operate against a couchdb cloud from a console-in-a-browser with the power of (and as a full alternative to) a unix system, and to think in terms of that cloud rather than in terms of services. The barrier between code and data will be much more blurred in practical terms because the cloud will host the services.
Over the last few days I've polished up my
notion that CouchDB can be a perfectly viable
application host, all on its own, without any
3rd tier between database and client. That
is, CouchDB is capable of serving standalone
applications. These standalone CouchDB
applications can be deployed to any working
CouchDB node and used from any browser.
I wish couch was based on IO rather than javascript, because with IO you can reverse algorithms out of running code. Hence processes could act as datasources if the VM was like IO. See http://hackety.org/2008/01/05/ioHasAVeryCleanMirror.html
"If the mechanisms to restrict access were in place the CouchDB backend could be exposed to the browser directly, removing the server side application code as a bottleneck."
Never, EVER expose a database to a client! Doesn't matter what types of controls you think you have, you must ALWAYS have some business logic in place to protect the data.
If the business logic is implemented in couchdb or implemented in serverside code, it's still business logic protecting the data.
It could be just as flawed, or even worse (e.g. sql injection allows malicious users to run database operations with no restrictions at all. If there were db level restrictions they could only destroy their own data).
This ALWAYS NEVER EVER type of mentality demonstrates exactly why CouchDB is simultaneously overhyped and condemned.
The biggest advantage of CouchDB - compared with its competition - seems to be the ability to create views to query the schema less dataset. If I have to do this in mysql, then I will
have to create and maintain seperate columns with indices; making sure that updates to the data gets propagated to these columns etc. Do any of the CouchDB alternatives provide a cleaner solution?
A bit early to write off the project, isn't it? The CouchDB devs have repeatedly stated that they're concentrating on getting it working right before making it fast. It's still in alpha, for crying out loud.
There are many positive aspects of Couch's MapReduce implementation. Sure, you can use Hadoop or what not for increased flexibility, but Couch gives you a baked-in storage system, universal HTTP interface, incremental views (big feature!), replication (another biggie) and a structure for it all to sit in, with a nice interface to boot. Sure, you could set that all up separately, but isn't there a lot of value having it all just there and working? And check out the MLs - chained reduce is a constant point of discussion; it's definitely on the roadmap.
The lack of strong authentication is also a puzzling point - how many people implement complex auth at the DB level in a web app?
He does have some good points - the overhead of setting up and pulling down a socket for each connection cannot be denied, but that seems solvable with persistent connections. Furthermore, Couch's stateless API and eTag integration offer powerful caching options.
One point that did strike home for me was about the lack of development direction - this does seem to be a problem. For example, the effort to make applications run directly from CouchDB seems speculative and pretty useless. If you're going to install erlang and CouchDb you may as well install an app server as well. But the BTree rewrite priortisation? There were good reasons for that: it was going to break backwards compatibility, so essential to do it ASAP.
All in all, decent points, but way premature. How about we at least get to beta first?
Then again, if this article rams home the huge importance of speed to the devs, maybe I shouldn't be arguing ...
[+] [-] tumult|17 years ago|reply
edit: in case it's not clear, I like couchdb a lot and I think it's absurd that people people are backlashing against it because some monkey coder dorks found it highly buzzword compliant and are making it popular, despite not understanding it at all. So you end up with people hating something because it's getting some limelight for whatever reason, and then also many of the people championing it don't know how to use it correctly to build an app or anything. It's like two layers of stupid.
[+] [-] pj|17 years ago|reply
CouchDB solves a subset of information problems. The relational model can solve a vastly greater amount of problems.
[+] [-] ambition|17 years ago|reply
[+] [-] jrockway|17 years ago|reply
Unfortunately, simple and stylish doesn't always win. I see lots of people riding fixed gear bikes in Seattle, for example. Actually, I don't see many people riding them, I see them walking them around because they have the wrong gearing for going up and down Seattle's many hills, and they can't actually ride them. In this case, simple and stylish is the wrong tool for the job -- they need a bike that can change gears. That may be inelegant, but it works really well.
CouchDB is the fixed gear bicycle of the database world.
[+] [-] masomenos|17 years ago|reply
[+] [-] nothingmuch|17 years ago|reply
[+] [-] brendano|17 years ago|reply
[+] [-] jrockway|17 years ago|reply
You do know that the author of this article wrote an object database, KiokuDB, right?
[+] [-] dualogy|17 years ago|reply
[+] [-] cturner|17 years ago|reply
Another idea that couchdb already does that is a necessary pre-requisite to this outcome (from http://jchrisa.net/drl/_design/sofa/_show/post/standalone_ap...):
I wish couch was based on IO rather than javascript, because with IO you can reverse algorithms out of running code. Hence processes could act as datasources if the VM was like IO. See http://hackety.org/2008/01/05/ioHasAVeryCleanMirror.html[+] [-] maukdaddy|17 years ago|reply
Never, EVER expose a database to a client! Doesn't matter what types of controls you think you have, you must ALWAYS have some business logic in place to protect the data.
[+] [-] nothingmuch|17 years ago|reply
It could be just as flawed, or even worse (e.g. sql injection allows malicious users to run database operations with no restrictions at all. If there were db level restrictions they could only destroy their own data).
This ALWAYS NEVER EVER type of mentality demonstrates exactly why CouchDB is simultaneously overhyped and condemned.
[+] [-] crc|17 years ago|reply
[+] [-] moe|17 years ago|reply
[+] [-] silentbicycle|17 years ago|reply
[+] [-] sho|17 years ago|reply
There are many positive aspects of Couch's MapReduce implementation. Sure, you can use Hadoop or what not for increased flexibility, but Couch gives you a baked-in storage system, universal HTTP interface, incremental views (big feature!), replication (another biggie) and a structure for it all to sit in, with a nice interface to boot. Sure, you could set that all up separately, but isn't there a lot of value having it all just there and working? And check out the MLs - chained reduce is a constant point of discussion; it's definitely on the roadmap.
The lack of strong authentication is also a puzzling point - how many people implement complex auth at the DB level in a web app?
He does have some good points - the overhead of setting up and pulling down a socket for each connection cannot be denied, but that seems solvable with persistent connections. Furthermore, Couch's stateless API and eTag integration offer powerful caching options.
One point that did strike home for me was about the lack of development direction - this does seem to be a problem. For example, the effort to make applications run directly from CouchDB seems speculative and pretty useless. If you're going to install erlang and CouchDb you may as well install an app server as well. But the BTree rewrite priortisation? There were good reasons for that: it was going to break backwards compatibility, so essential to do it ASAP.
All in all, decent points, but way premature. How about we at least get to beta first?
Then again, if this article rams home the huge importance of speed to the devs, maybe I shouldn't be arguing ...
[+] [-] nothingmuch|17 years ago|reply
"Personally I would much rather see feature completeness first"