couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: About denormalization and keep consistent
Date Sat, 10 Apr 2010 00:37:11 GMT
	What about turning the problem on it's head. It sounds like a  
document can have one author and the author can have one name. What  
about storing the _id of the author doc in each document they write/ 
own then use a view that emits the document _id and the author _id.  
Querying that with include_docs=true will pull in both documents (if I  

  correctly) so you'd see the document the author wrote and the author  
document. That means if the authors name changes you have one place  
(one document) to update, which is trivial.
	Of course, the above breaks if the author actually changes (a new  
name because the author _id has changed) but you already have a  
solution for that problem with _changes et. al. ;) If changing a  
document author is global (e.g. all docs authored by Joe are all now  
authored by Fred) the above should work, you could even have a view  
that emits doc id by author that you query with ?key and have your  
external process reduce to zero, you could even take that view result  
and push a bulk update (though that might not be ideal if a document  
is large...).

On 10 Apr 2010, at 00:56, faust 1111 wrote:

> In my case
> change of author name is exceptional situation.
> its happen rarely.
> I think  i can do like this:
>  when author change name
>  i create doc mark that i begin update all related contents
>  then  try update
>  then remove mark
> if update is fail(mark not reomve), i will know about and can  
> continue.
> And i think i don't need  run backend process listen
> _changes feed i can  catch changes in my app model Author.
> 2010/4/10 Michael Ludwig <>:
>> Andrew Melo schrieb am 09.04.2010 um 15:04:59 (-0500)
>> [Re: About denormalization and keep consistent]:
>>>> Are there scenarios where writing happens to an SQL server, from
>>>> where NoSQL replicas are fed and used to serve readers?
>>> Possibly. But, if you're writing to a single SQL master, then you  
>>> lose
>>> two benefits of Couch: horizontally scalable writes and not having  
>>> to
>>> be restricted by SQL's data model. You could do (for instance)  
>>> single
>>> master writes and many-slave reads on a stock SQL server in that  
>>> case.
>> Thanks, Andrew. It appears Faust is concerned about data consistency
>> which is usually and easily ensured by suitable SQL data modeling.  
>> That
>> does not happen to be the forte of a system designed for  
>> scalability at
>> the expense of consistency.
>> Faust, there are many places and cases where data can be copied and  
>> held
>> redundantly in hundreds or thousands of places, and it simply doesn't
>> matter. Think email, for example. If you changed the name belonging  
>> to
>> your email address to "Johann Faust", it wouldn't matter that there  
>> are
>> mails with the older version of your name in the archive, and they
>> wouldn't have to be updated, and they even shouldn't be updated. That
>> seems to be an excellent use case for a system like CouchDB.
>> If, on the other hand, you care about consistency in the way you
>> described, you might want to consider using a system that supports
>> you in guaranteeing such consistency.
>> --
>> Michael Ludwig

View raw message