Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 84615 invoked from network); 9 Feb 2009 16:05:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 16:05:30 -0000 Received: (qmail 59675 invoked by uid 500); 9 Feb 2009 16:05:28 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 59645 invoked by uid 500); 9 Feb 2009 16:05:28 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 59634 invoked by uid 99); 9 Feb 2009 16:05:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 08:05:28 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [80.68.93.145] (HELO www.astoryforbedtime.com) (80.68.93.145) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 16:05:19 +0000 Received: from 98.65.adsl.brightview.com ([80.189.65.98] helo=[192.168.2.101]) by www.astoryforbedtime.com with esmtp (Exim 4.63) (envelope-from ) id 1LWYd0-000205-8E for user@couchdb.apache.org; Mon, 09 Feb 2009 16:04:58 +0000 Message-ID: <49905424.8020804@theopenlearningcentre.com> Date: Mon, 09 Feb 2009 16:04:52 +0000 From: Alan Bell User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: [user] Re: The Blog 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> <20090209152738.GS21180@tumbolia.org> <6a8c90ba0902090755i575bc907qcc35b62e4d7c80b1@mail.gmail.com> In-Reply-To: <6a8c90ba0902090755i575bc907qcc35b62e4d7c80b1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 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 >> >> > >