You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Wout Mertens <wm...@cisco.com> on 2009/02/09 16:18:09 UTC
Re: [user] Re: The Blog
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.
Re: [user] Re: The Blog
Posted by Wout Mertens <wm...@cisco.com>.
On Feb 9, 2009, at 4:50 PM, Jan Lehnardt wrote:
> On 9 Feb 2009, at 16:18, 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.
>
> Quoting myself from a few mails ago:
>
>> CouchDB solves the[sic] similar problems as an RDBMS, but starting
>> from a different angle (distributed operation instead of single-node
>> operation, CAP, yadda yadda).
>
> The differences as a consequence of different CAP-feature priorization
> would be interesting, but then, I had hoped that the "Eventual
> Consistency"*
> chapter had done that.
>
> * http://books.couchdb.org/relax/eventual-consistency
Funny how nobody is really upset about the schema missing versus
RDBMS. It seems like schemas are a lot like static typing in
programming languages - no matter how you look at it, there are a
*lot* of people doing just fine without it.
I remember taking Databases at university and we had to read this book
(forgot which one but it's pretty much the standard) and the schema
and relational concepts are very intertwined. I really liked the
theory where you would make a fully decomposed DB schema and then used
queries to tie everything together. The thing I liked best was
writeable queries, basically if you are careful you can automatically
update the underlying tables except in some edge cases, thanks to a
strict schema. However, as far as I know no current RDBMS implements
this. Maybe there isn't much use for schemas. Non-trivial applications
can't rely on just schemas for data validation.
A thought occurred: If you are consistent in interfacing with your
database using only views, then you have created an ad-hoc schema.
This is probably old news to most of you but it felt nice realizing
it ;-)
So basically I'm saying maybe schema-free should be touted more as a
nice-to-have feature?
Wout.
Re: [user] Re: The Blog
Posted by Jan Lehnardt <ja...@apache.org>.
On 9 Feb 2009, at 16:18, 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.
Quoting myself from a few mails ago:
> CouchDB solves the[sic] similar problems as an RDBMS, but starting
> from a different angle (distributed operation instead of single-node
> operation, CAP, yadda yadda).
The differences as a consequence of different CAP-feature priorization
would be interesting, but then, I had hoped that the "Eventual
Consistency"*
chapter had done that.
* http://books.couchdb.org/relax/eventual-consistency
Cheers
Jan
--
Re: [user] Re: The Blog
Posted by Jan Lehnardt <ja...@apache.org>.
On 9 Feb 2009, at 18:28, Paul Davis wrote:
> On Mon, Feb 9, 2009 at 11:43 AM, Adam Petty <ad...@gmail.com>
> wrote:
>> If a hospital starts to move to an SOA - and all the business logic
>> gets
>> abstracted to the web services that each department exposes in the
>> use,
>> transmission (security) of data... wouldn't that then become almost
>> the
>> perfect place for couch?
>>
>> Now if it's already in Oracle - I can see how it might not be smart
>> to
>> retool just for couch, but starting from scratch, I can't think of
>> anything
>> that goes on in a hospital that doesn't revolve around physical
>> documents.
>>
>> I've done consulting for medical records processing companies - but
>> not for
>> hospitals themselves - any specifics as to why this wouldn't meet
>> requirements?
>>
>>
>
> I saw the schema for an Oracle db used in production at a teaching
> hospital. It still gives me nightmares. This was the general business
> database not related to things like patient records etc. Ie, it tracks
> which doctor is on what rotations in which department. AFAIK, it
> basically ran everything *except* patient records. Personally I'd
> probably pick up a commercial solution for things like medical records
> for liability alone.
I think for the sake of the argument we're assuming that we're building
a new commercial solution on top of CouchDB.
> The larger picture here though is when business logic and consistency
> are more important than availability and partition tolerance. These
> are systems that are designed to be run on a single machine with
> perhaps a hot spare etc.
A double-write proxy in front of the master & hot spare and not using
replication gives you CA!P instead of !CAP. CouchDB lets you even
make the choice. It is moar bettar! :)
Cheers
Jan
--
> In other words, these are not your Web 2.0 "Let's have an ORMgy!"
> databases.
>
>>
>>
>> On Mon, Feb 9, 2009 at 11:12 AM, Paul Davis <paul.joseph.davis@gmail.com
>> >wrote:
>>
>>> On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens <wm...@cisco.com>
>>> 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.
>>>>
>>>
>>> If you stuff a structured string into an RDBMS you're Doing It Wrong
>>> ™.
>>>
>>>> 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.
>>>>
>>>
>>> Things that CouchDB is better at:
>>>
>>> The interweb.
>>>
>>> Things that an RDBMS is better at:
>>>
>>> Huge amounts of business logic. As in the Oracle install running
>>> your
>>> favorite hospital. Think along the lines of 10's and 100's of
>>> thousands of lines of app logic in the DB itself.
>>>
>>> HTH,
>>> Paul Davis
>>>
>>
>
Re: [user] Re: The Blog
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Feb 9, 2009 at 11:43 AM, Adam Petty <ad...@gmail.com> wrote:
> If a hospital starts to move to an SOA - and all the business logic gets
> abstracted to the web services that each department exposes in the use,
> transmission (security) of data... wouldn't that then become almost the
> perfect place for couch?
>
> Now if it's already in Oracle - I can see how it might not be smart to
> retool just for couch, but starting from scratch, I can't think of anything
> that goes on in a hospital that doesn't revolve around physical documents.
>
> I've done consulting for medical records processing companies - but not for
> hospitals themselves - any specifics as to why this wouldn't meet
> requirements?
>
>
I saw the schema for an Oracle db used in production at a teaching
hospital. It still gives me nightmares. This was the general business
database not related to things like patient records etc. Ie, it tracks
which doctor is on what rotations in which department. AFAIK, it
basically ran everything *except* patient records. Personally I'd
probably pick up a commercial solution for things like medical records
for liability alone.
The larger picture here though is when business logic and consistency
are more important than availability and partition tolerance. These
are systems that are designed to be run on a single machine with
perhaps a hot spare etc.
In other words, these are not your Web 2.0 "Let's have an ORMgy!" databases.
>
>
> On Mon, Feb 9, 2009 at 11:12 AM, Paul Davis <pa...@gmail.com>wrote:
>
>> On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens <wm...@cisco.com> 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.
>> >
>>
>> If you stuff a structured string into an RDBMS you're Doing It Wrong
>> ™.
>>
>> > 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.
>> >
>>
>> Things that CouchDB is better at:
>>
>> The interweb.
>>
>> Things that an RDBMS is better at:
>>
>> Huge amounts of business logic. As in the Oracle install running your
>> favorite hospital. Think along the lines of 10's and 100's of
>> thousands of lines of app logic in the DB itself.
>>
>> HTH,
>> Paul Davis
>>
>
Re: [user] Re: The Blog
Posted by Adam Petty <ad...@gmail.com>.
If a hospital starts to move to an SOA - and all the business logic gets
abstracted to the web services that each department exposes in the use,
transmission (security) of data... wouldn't that then become almost the
perfect place for couch?
Now if it's already in Oracle - I can see how it might not be smart to
retool just for couch, but starting from scratch, I can't think of anything
that goes on in a hospital that doesn't revolve around physical documents.
I've done consulting for medical records processing companies - but not for
hospitals themselves - any specifics as to why this wouldn't meet
requirements?
On Mon, Feb 9, 2009 at 11:12 AM, Paul Davis <pa...@gmail.com>wrote:
> On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens <wm...@cisco.com> 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.
> >
>
> If you stuff a structured string into an RDBMS you're Doing It Wrong
> ™.
>
> > 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.
> >
>
> Things that CouchDB is better at:
>
> The interweb.
>
> Things that an RDBMS is better at:
>
> Huge amounts of business logic. As in the Oracle install running your
> favorite hospital. Think along the lines of 10's and 100's of
> thousands of lines of app logic in the DB itself.
>
> HTH,
> Paul Davis
>
Re: [user] Re: The Blog
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens <wm...@cisco.com> 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.
>
If you stuff a structured string into an RDBMS you're Doing It Wrong ™.
> 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.
>
Things that CouchDB is better at:
The interweb.
Things that an RDBMS is better at:
Huge amounts of business logic. As in the Oracle install running your
favorite hospital. Think along the lines of 10's and 100's of
thousands of lines of app logic in the DB itself.
HTH,
Paul Davis
Re: [user] Re: The Blog
Posted by Alan Bell <al...@theopenlearningcentre.com>.
banking should work just fine. I wrote an application in Notes called
puffin (personal finances in Notes) and I was thinking about reviving it
as puffic or something.Each transaction is a document, each account is a
view. A document has a source account, a destination account and a
value. It appears as a positive value in the destination account and a
negative in the source account. Thus buying a newspaper might debit the
"wallet" account and credit the "books and periodicals" expense account.
Taking cash from an ATM would debit the current acccount and credit the
wallet.
Adam Petty wrote:
> Well -- Its sounds like couch is starting to be able to stand up to the
> fire... which is why I'm digging this thread.
>
> But yes - too much heat and the whole proprietary/RDBMS community could
> start aiming bazooka's at it - which might do some damage. So maybe some
> middle ground somewhere..
>
> I'll work on a compilation - and post it and see where the wiki takes it. I
> would have to agree that there is something to google's jedi strategy with
> microsoft...
>
> "nothing to see here... these aren't the droids you're looking for... of
> course we're not competing with microsoft"
>
> -- and can keep that in mind also
>
> okay enough about that -
>
> Just as a frame of reference... the only thing that has held couch back for
> development at my work - has been the lack of a pluggable reporting tool. I
> know that is really just semantics - that Pentaho can use an XML dataset -
> and JSON - XML translation seems easy BUT.... nothing out of the gate yet.
> In my case - bosses love names -- SSRS, 10g, CrystalReports, Business
> Objects..etc.
>
> -- as for an example db issue...
> For some reason - without transactions the RDBMS people at my work seem to
> not want to consider couch for anything having to do with money.
>
> I know it would be fairly simple to have an "accounts" array field on a JSON
> user-account document - that way no single "enities" account could be
> changed by more than one write at the same time... seems rediculously simple
> - but is there a case where this could fail?
>
> Seems like money is always the most sensitive issue - if we could develop a
> very usable "banking" example db secenario - maybe an artificial bank app?
> and see if we can break it - or get out of sync balances due to timing
> issues -- etc?
>
> .02$
>
>
>
>
>
>
> On Mon, Feb 9, 2009 at 10:27 AM, Noah Slater <ns...@apache.org> wrote:
>
>
>> On Mon, Feb 09, 2009 at 04:18:09PM +0100, Wout Mertens wrote:
>>
>>> 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.
>>>
>> Not really, I just like avoiding the flames. Heh heh.
>>
>> I see where you want to go with this, and I agree that some applications
>> are
>> better suited to CouchDB, but I think it's often a blurry line, and you
>> will
>> draw fire from the RDBMS people for anything too concrete.
>>
>> --
>> Noah Slater, http://tumbolia.org/nslater
>>
>>
>
>
Re: [user] Re: The Blog
Posted by Justin Sheehy <ju...@iago.org>.
Adam,
On Mon, Feb 9, 2009 at 10:55 AM, Adam Petty <ad...@gmail.com> wrote:
> For some reason - without transactions the RDBMS people at my work seem to
> not want to consider couch for anything having to do with money.
You should direct your colleagues to Pat Helland, a luminary in
RDBMS's and transactions:
http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx
-Justin
Re: [user] Re: The Blog
Posted by Jan Lehnardt <ja...@apache.org>.
On 9 Feb 2009, at 16:55, Adam Petty wrote:
> -- as for an example db issue...
> For some reason - without transactions the RDBMS people at my work
> seem to
> not want to consider couch for anything having to do with money.
Somebody should tell them that banks have since moved
to eventually consistent data storage for most but the most
heavyweight (money-)transactions.
Cheers
Jan
--
>
>
> On Mon, Feb 9, 2009 at 10:27 AM, Noah Slater <ns...@apache.org>
> wrote:
>
>> On Mon, Feb 09, 2009 at 04:18:09PM +0100, Wout Mertens wrote:
>>> 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.
>>
>> Not really, I just like avoiding the flames. Heh heh.
>>
>> I see where you want to go with this, and I agree that some
>> applications
>> are
>> better suited to CouchDB, but I think it's often a blurry line, and
>> you
>> will
>> draw fire from the RDBMS people for anything too concrete.
>>
>> --
>> Noah Slater, http://tumbolia.org/nslater
>>
Re: [user] Re: The Blog
Posted by Adam Petty <ad...@gmail.com>.
Well -- Its sounds like couch is starting to be able to stand up to the
fire... which is why I'm digging this thread.
But yes - too much heat and the whole proprietary/RDBMS community could
start aiming bazooka's at it - which might do some damage. So maybe some
middle ground somewhere..
I'll work on a compilation - and post it and see where the wiki takes it. I
would have to agree that there is something to google's jedi strategy with
microsoft...
"nothing to see here... these aren't the droids you're looking for... of
course we're not competing with microsoft"
-- and can keep that in mind also
okay enough about that -
Just as a frame of reference... the only thing that has held couch back for
development at my work - has been the lack of a pluggable reporting tool. I
know that is really just semantics - that Pentaho can use an XML dataset -
and JSON - XML translation seems easy BUT.... nothing out of the gate yet.
In my case - bosses love names -- SSRS, 10g, CrystalReports, Business
Objects..etc.
-- as for an example db issue...
For some reason - without transactions the RDBMS people at my work seem to
not want to consider couch for anything having to do with money.
I know it would be fairly simple to have an "accounts" array field on a JSON
user-account document - that way no single "enities" account could be
changed by more than one write at the same time... seems rediculously simple
- but is there a case where this could fail?
Seems like money is always the most sensitive issue - if we could develop a
very usable "banking" example db secenario - maybe an artificial bank app?
and see if we can break it - or get out of sync balances due to timing
issues -- etc?
.02$
On Mon, Feb 9, 2009 at 10:27 AM, Noah Slater <ns...@apache.org> wrote:
> On Mon, Feb 09, 2009 at 04:18:09PM +0100, Wout Mertens wrote:
> > 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.
>
> Not really, I just like avoiding the flames. Heh heh.
>
> I see where you want to go with this, and I agree that some applications
> are
> better suited to CouchDB, but I think it's often a blurry line, and you
> will
> draw fire from the RDBMS people for anything too concrete.
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: [user] Re: The Blog
Posted by Noah Slater <ns...@apache.org>.
On Mon, Feb 09, 2009 at 04:18:09PM +0100, Wout Mertens wrote:
> 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.
Not really, I just like avoiding the flames. Heh heh.
I see where you want to go with this, and I agree that some applications are
better suited to CouchDB, but I think it's often a blurry line, and you will
draw fire from the RDBMS people for anything too concrete.
--
Noah Slater, http://tumbolia.org/nslater
Re: [user] Re: The Blog
Posted by Jan Lehnardt <ja...@apache.org>.
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.
>
>
Re: [user] Re: The Blog
Posted by Alan Bell <al...@theopenlearningcentre.com>.
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.
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.