incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brit Gardner" <b...@figarointeractive.com>
Subject Re: Thinking outside the RDBMS box - how do I... ?
Date Tue, 28 Oct 2008 17:39:50 GMT
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 <ara.t.howard@gmail.com>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
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message