> -----Original Message-----
> Different industries may have some particular legal requirements; that
> will generally surround there being a need to specifically _preserve_
> information for some number of years, as opposed to needing
> to _get rid_
> of data at the end of the year.
True. I was only thinking that it might make sense, particularly if we don't
use a DB to be able to take last years data and put it in a file on its own
and store that to tape and start using a clean file for this year. However
as you said, with a DB it is less of a hassle to keep the data in the DB.
>
> "Getting rid of data" has tended to be driven by the
> pragmatic issues of:
> a) Only needing to report on the current calendar year, and
> having paper
> sets of books where recalculating things by hand is daunting;
And you can put the paper books in a cupboard somewhere and get them out
later if you need to.
> b) Only having 5MB of disk space on early Winchester Hard
> Drives so that
> you only have space to store very limited amounts of data;
Less of a problem these days, but even 16Gb drives fill up.
> c) Having so Vastly Many Transactions per year that you need to purge
> data out regularly lest you need to dig an extra basement to hold
> the ever-increasing racks of disk drives. [My employer
> has a bunker
> of much this nature to hold the 17 mainframes, some of which were
> likely involved the last time you booked an airline ticket; they
> have to purge data out pretty regularly as there's just
> too much data
> to comfortably cope with...]
I am glad that that is not my job.
> > It still might be nice to be able to archive, but I suppose
> that we could
> > just use the archiving stuff in the DB for that?
>
> Not really; DB "archive logs" tend to be used to ensure that data
> doesn't get lost; the archiving that "takes stuff out of the DB" is at
> the other end of the process.
i.e. we want to lose it. (smile)
>
> It would make sense to create SQL queries to carefully "throw
> data away"
> when appropriate.
>
> > > After all, if:
> > > a) Account balances keep having to be repetitively
> calculated from the
> > > beginning of time until now, That'll Be Slow.
> >
> > Lets hope we can tell the DB to start calculating from the
> changed point
> > only.
>
> Yes, that's doubtless one of the design criteria. One, by
> the way, that
> effectively rules out MySQL, as it doesn't do triggers...
A case for a feature request to MySQL?
>
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
