Managing the database size

[Colin Law]

On 27 December 2015 at 20:47, Colin Law <clanlaw at gmail.com> wrote:
> On 27 December 2015 at 00:39, aeneas <receiver at gowdygroup.net> wrote:
>> GNUcash is something that is used constantly over a long period of time
>> (i.e., ideally a lifetime or even more).  As such the amount of data
>> contained in the database grows and eventually becomes a problem.  How long
>> that takes depends on many things and will be different for just about
>> everyone.  However, software like this requires some kind of archiving
>> capability.  Insofar as it is desirable to also retain a large amount of
>> historical data the archiving process requires the ability to perform some
>> kind of operation that preserves data older than a specified date in a file,
>> which I'm calling an archive, and flushes (i.e., removes) that same older
>> data from the active file.
>>
>> I'm just now considering whether or not I want to invest the time and effort
>> to adopt the use of GNUcash but couldn't find any information about how to
>> archive in the available documentation.  Hopefully this is just a matter of
>> my ignorance about the terminology that might be employed with this
>> software.
>>
>> I'd appreciate any advice on how to figure out how to do archiving.
>
> Does not closing the books do this?  I have never had to do this as I
> think processor power and disk size is increasing faster than my books
> are so after about 12 years of personal data it still only takes
> around 20 seconds to load the data, which is rather less than it did
> after the first year I think.  In the longer term when full database
> support is added there will be no need to archive data at all
> performance should not suffer significantly even with enormous amounts
> of data.

Having looked at what closing the books the does I see it will not
reduce the size of the data.  However, my suggestion that in the long
term it will not be a problem still stands.  Once full sql support is
added it will not be a problem.  There will never be a need to reduce
the size of the database.

Colin