incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Bell <>
Subject Re: [user] Re: The Blog
Date Mon, 09 Feb 2009 16:04:52 GMT
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 

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 <> 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,

View raw message