Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: 83.97.50.139 is neither permitted
 nor denied by domain of jan@apache.org)
Message-Id: <453864EA-2182-4689-A65C-9DDB0FEF9FE7@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <4990523C.5090301@theopenlearningcentre.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [user]  Re: The Blog
Date: Mon, 9 Feb 2009 17:09:31 +0100
References: <5186956f0902082052m43546a8dmb6d9a3ebf9685034@mail.gmail.com>
 <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com>
 <5186956f0902090338i2829df1erebaa24a4feea7e06@mail.gmail.com>
 <5186956f0902090449s76befd76g4cf9ded9f59efc86@mail.gmail.com>
 <5186956f0902090627y1239b12es505ee80b2d6bd248@mail.gmail.com>
 <6a8c90ba0902090651q258bb335uf6142ccb25261931@mail.gmail.com>
 <20090209145701.GR21180@tumbolia.org>
 <2B705A9C-441C-487C-95E7-B537682F49A7@cisco.com>
 <4990523C.5090301@theopenlearningcentre.com>


On 9 Feb 2009, at 16:56, Alan Bell wrote:

> selling airline tickets was always the classical problem you  
> couldn't do with Notes because you might overbook because of the  
> distributed system means no atomic updates and stock level checking.  
> That actually just shows how much older Notes is than the modern  
> airline where overbooking is standard policy. Anyhow an application  
> where there are multiple purchasers and a finite stock and the stock  
> levels must never ever be overcommitted probably gives the RDBMS an  
> advantage.

A single node CouchDB or a double-write (note, not
2-phase-commit) pair can handle this pretty well. It just
has limitations that true p2p setups don't have.

Cheers
Jan
--


> Wout Mertens wrote:
>> On Feb 9, 2009, at 3:57 PM, Noah Slater wrote:
>>
>>> On Mon, Feb 09, 2009 at 09:51:18AM -0500, Adam Petty wrote:
>>>> Could this thread be added to the wiki - with only minor editing  
>>>> for length
>>>> - maybe as "a RDBMS vs couch 'Discussion' ?"  or something  
>>>> similar?"...
>>>
>>> We've learnt from the book that such comparisons tend to be harmful.
>>>
>>> They lead people into thinking that there is a direct meaningful  
>>> comparison.
>>>
>>> Fundamentally, CouchDB and RDMS solve different problems.
>>
>> I dunno, I think it would be interesting to compare the main  
>> benefits of each so that you know what the strong points of each are.
>>
>> For example, suppose you implement schema-free in an RDBMS by  
>> adding a text field that contains a JSON string. You still keep  
>> some of the metadata, like _rev and _id, in proper fields.
>>
>> However, thinking about that, it means you will need to re- 
>> implement everything CouchDB does, like views and replication.
>>
>> To be honest, I think saying RDBMS and CouchDB are for different  
>> solutions is just you guys being nice. I think that any application  
>> would benefit from using the CouchDB model and only in very  
>> specific, very demanding cases an RDBMS would be better. I can't  
>> think of any examples though.
>>
>> So here's my challenge to the mailing list, it's pretty much the  
>> same one that MrDonut posted: Give us an example of something that  
>> would be better be done with an RDBMS and something that would  
>> better be done with CouchDB.
>>
>> I'll help you: I think it would be easier to create a wiki with  
>> CouchDB than with an RDBMS. It is possible in both but CouchDB just  
>> makes it easier. I suppose we'd have to ask the http://couch.it  
>> guys to know if that's true.
>>
>> I don't know what would be done better in an RDBMS. Performance  
>> logging perhaps? Something with really stringent schema requirements?
>>
>> Wout.
>
>