>
> You have just identified the problem and solution that CouchDB solves
> with using a traditional RDBMS in a distributed environment. Check out
> the discussion on the CAP hypothesis (Others call it a theorem, I'm
> not convinced, but the basic idea is there).
>
> Or more succinctly, guaranteed uniqueness requires global state,
> global state does not scale.
>
> HTH,
> Paul Davis
>
Yeah, that's what I thought but I was hoping for something in between.
That is, all I want to do is guarantee uniqueness on one or a set of fields.
It seems to me that it would not require locks on reads and most of eventual
consistency would be okay except for when dealing with an INSERT or an
UPDATE that changes the unique field. All other cases could work just like
before. It would only require a special locked lookup on the unique field or
field set which could be optimized.
I know that CouchDB is not a solution to all problems (nor do I think it
should be) but it seems that this would be common for most web applications
which is a major CouchDB target. For example, almost any website needs
unique user_names. They also need unique names for pages in a wiki. Blogs
that use named pages would also have this problem.
In other words, this seems like an issue that happens so often in the web
computing world that I wonder if it should be supported in CouchDB.
Of course, the argument is to push that global state into the application
layer and store it elsewhere; however, the question is whether that
complexity would better service the developer if it was (a) in CouchDB or
(b) in the application itself.
Since it is a common case (as opposed to an edge case), perhaps there could
be some discussion of putting it into CouchDB.
Seriously though, would this not affect 100% of websites with a user base?
One solution, I suppose, is to store the user data in an SQL database, but I
prefer having as much as possible in CouchDB due to its flexible schemas.
Sunny