On Jun 30, 2011, at 11:37 PM, Zdravko Gligic wrote: > Then there is the whole issue of servers (where much of this makes > sense because of scalability) vs clients (where very little of this > makes any sense because there are no multi-user concurrency issues).
Sure there are. I’ve spent my career working on client-side software and concurrent access to databases has definitely been an issue in some cases. Just think of multiple processes instead of users. As an example, I worked on the “PubSub” RSS/Atom framework for Mac OS X. This uses a sqlite database to store the user’s feed subscriptions and current article set. At any time you could have the following going on simultaneously: - user reading articles in Safari or Mail, implicitly marking them as read - MobileMe synchronizing the read/unread state of articles between this computer and another one - background daemon fetching feeds from the net and adding new articles - another task in the daemon deleting old articles to save room There were definitely availability problems at times, especially soon after user login when several of these might be going on simultaneously and disk bandwidth is otherwise constrained because lots of apps are starting up. > On top of that, when the same issues are raised with regard to mobile > devices, the prevalent answer is "oh, those clients only need a much > smaller subset". So, when it comes to CouchDB on client devices, one > is left with an impression that it is not really a database for > storing hundreds nor even tens of thousands of records but mere dozens > or few hundreds of key/value pairs. You’re exaggerating what I (and others) said. My point was that the typical data set on a mobile device is a lot smaller than the typical data set on a server, both because it’s only one user’s data instead of thousands, and because the tasks are often different. But by ‘smaller’ I didn’t mean ‘toy-sized’. > Never mind the fact that good > number of apps need SQLite-like querying capabilities - right down to > full text searching and table joining. You can add full-text search to CouchDB, just as people were using external text indexers with sqlite before one got built into it a few years ago. Apps don’t need table joining per se — they need the ability to query based on combinations of the contents of related records, and joins are the particular kind of hammer that does that job in a relational db. CouchDB’s views support this quite well, it’s just a different mechanism than what you’re used to. (CouchDB also allows the schema to be denormalized compared to what you’d do in a relational db, which lessens the need for combining records.) —Jens
