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: local policy)
MIME-Version: 1.0
In-Reply-To: <a6e65e8d0904141852i5fc16452jb06c395c8c7451d2@mail.gmail.com>
References: <a6e65e8d0904122315s19eedbdcg61ce4b22ee3b162@mail.gmail.com>
	 <1A8CEBA7-32CF-4D47-BE52-6D31DB79B385@mac.com>
	 <55047b710904130929g451af4abw62e6ccd7281fbd77@mail.gmail.com>
	 <a6e65e8d0904141852i5fc16452jb06c395c8c7451d2@mail.gmail.com>
Date: Wed, 15 Apr 2009 13:04:01 +1000
Message-ID: <55047b710904142004m29d835b9n696d55e2335971d6@mail.gmail.com>
Subject: Re: using CouchDB for a finance manager?
From: Nicholas Orr <nicholas.orr@zxgen.net>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd28aa816700804678f3314

--000e0cd28aa816700804678f3314
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I think that the balance should not be persistent.If you are going to show
all the transactions on the screen you can calculate the balance.
Then if a transaction is deleted it can show the updated balance.

Plus using Map/Reduce it is fairly simple for couch to give an accurate and
quick balance in the reduce part. Remember that the index is updated every
time a document is added or removed. The first time the view is created it
has to create the index, once this is done if a document is added the index
is updated by the single doc, like wise for a deletion.

Thinking out loudly (as above) there is going to be some time spent
calculating the balances all the time, however this can be optimised later
by caching smartly in the app layer. Map/Reduce is pretty powerful once you
get used to how it works. I've found it pretty neat and I've only being
using it for a few weeks.

Nick

At least if you go down this path, of non-persistent balances, you'll be
right. Work

On Wed, Apr 15, 2009 at 11:52 AM, Li Zhengji <zhengji.li@gmail.com> wrote:

> Thanks for your information that makes me confident to use CouchDB for
> this task.
>
> Before getting start, I think to calculate the balance seems
> difficult, no matter it is schema-less or not.
>
> For example, if I delete a older transaction, then all balance in
> following transactions must be updated one after another. For CouchDB,
> maybe some views need to be rebuilt, too. It seems to be time
> consuming. (Suppose there is a balance field in each transation ---
> CouchDB doc.)
>
> Any idears for this?
>
> 2009/4/14 Nicholas Orr <nicholas.orr@zxgen.net>:
> > I've looked into doing my own accounting app as well. Sitting with an
> > accountant the main thing she had an issue with, in regard to all the
> > products currently available, is tracking what the amount is for on each
> > side of the transaction.
> >
> > Example, say I as an individual transfer $10K into a company I'm a
> director
> > of. On the individual side (withdraw) of the transaction info needs to be
> > recorded as one thing, then on the other side (deposit) different
> > information needs to be recorded. This whole transaction needs to exist
> in
> > both places so come tax time the account doing the work for tax can
> follow
> > everything simply.
> >
> > The concept of schema-less documents now starts to shine as ideal. I have
> a
> > few other projects on the go right now and will not be getting to this
> one
> > anytime soon. Interested in what you guys come up with :)
> >
> > Nick
> >
> >
> >
> --
> Li Zhengji
> -------------------------------------------------------------
> If all you have is a hammer, everything is a nail.
> -------------------------------------------------------------
>

--000e0cd28aa816700804678f3314--