Great - thanks for the in-depth response, Chris. I believe I follow what yall are talking about with the denormalization of the phone numbers and how it may lead to difficulties with future updates if phone numbers are keyed.
Fortunately, this specific usage shouldn't run into that issue - I used the term 'phone number' to simplify the scenario, but what we are actually receiving from the carriers is a unique id that represents an 'install' of the application on a phone. So if a user changes phone numbers but keeps the same phone, the unique id and hence our view keys are solvent. If a user changes phones, or deletes the application and re-installs it, they are assigned another unique install id - which is covered here because we will simply update the group documents with that new id AND leave the old id in place. The documents tied to the old ID are still fetched correctly through the group. To expand a little on the specifics of this situation - our client has graciously allowed us to parallel develop in a traditional RDBMS and couchdb. They're excited about the potential benefits of couch and how their data and implementation fit couch perfectly (they are building completely in the cloud - EC2, EBS, S3, etc - so we plan to rely on the distribution properties of couch in the future). I broached the subject with our client because I'm fascinated with the map-reduce, JSON document, HTTP, and erlang implementation of couchdb and how it can serve applications better than SQL-based systems. But I am what some would call a total newb in the map-reduce realm. I'm hoping to put together some data comparing the two systems against each other. I understand that couch isn't even at a 1.0 release yet, and I am not expecting it to perform up to par with MySQL at this point. But hopefully with yall's help I won't be feeling around too much in the dark on getting this system up and running! And hopefully I will be able to share the data back into the community. On Tue, Oct 28, 2008 at 12:11 PM, ara.t.howard <[EMAIL PROTECTED]>wrote: > > On Oct 28, 2008, at 10:48 AM, Chris Anderson wrote: > > >> Remember that _bulk_docs updates happen inside a transaction. If any >> of the updates fails, then none of them are applied. So there's no >> chance of inconsistency. >> > > > hrrrm - technically i suppose that is true but, currently, conflicts are > impossible to detect: if you did an update of 1000 docs and one collided > you'd have no way (programatically) to take corrective action since the > cause of the conflict is not reported - if it were, then this would seem > like a viable option - i know we talked about that before though and that > it's on the radar - but just thought i'd through that out there: > denormalizing the phone numbers does set one up for a bulk update scenario - > moving the phone numbers into another doc might help this... > > > a @ http://codeforpeople.com/ > -- > we can deny everything, except that we have the possibility of being > better. simply reflect on that. > h.h. the 14th dalai lama > > > >
