DBMS Usage

[Christopher Browne]

> In a message dated: 03 Apr 2002 10:08:34 EST
> Derek Atkins said:
> 
> >Paul Lussier <plussier@mindspring.com> writes:
> >
> >> Has no one else here read The UNIX Philosophy?  Keep it simle, and 
> >> keep it text.  If you need it to load faster, buy a faster CPU, 
> >> they're cheap now-a-days :)
> >
> >I agree that CONFIGURATION files should be kept text.  But why data
> >files?  Data files are application-specific, so why should you be
> >restricted to ascii data files, especially when the data is not
> >necessary human-readable in the first place?
> 
> Today that file is application specific to gnucash.  Tomorrow it may 
> be shared by a contact management application like the Evolution 
> contact engine, or may be accessed by a budgeting program, a Bill of 
> Materials management application.  You have no idea where the future 
> will lead.  Therefore, why tie yourself to an inflexible format.

I don't think anybody is arguing for an 'inflexible data format,' so it
seems to me that you're playing a straw man argument here.

> >The point of moving away from XML (IMHO) is _not_ just to load faster.
> >Also note that the load speed is NOT just a factor of CPU, but a
> >factor of the XML implementation and overhead of processing.  It also
> >takes a heck of a lot of core.

> Keep in mind, I never said that you had to stick with XML, all I said
> was that I find far more value in an ASCII text file than I do in a
> binary data format.  I don't care whether it's in XML, SGML, HTML, or
> some other format, as long as I can look at it and edit it with my
> text editor of choice in a terminal window without the requirement of
> X is all that matters.

Editing the existing XML file is not all a bed of roses, by the way.

> >So, while speed is ONE goal, it is not all of it.  By using a database
> >you also:
> >        a) obviate the need to transaction log file
> >        b) obviate the need for "backup" files

> Don't databases keep transaction logs and backup files?  What happens
> when the system crashes because of a power outage in the middle of of
> a transaction?  Now you've got a corrupt binary file that contains all
> your data and it's essentially useless.

The use of a database obviates the need _for the application_ to
maintain transaction logs and backup files.

The DBMS has to have a "transaction log" and some scheme for doing
backups.

In a sense, the improvement is a bit illusory as it's more than likely
to merely push it out outside of the user's awareness.

> >        c) load faster
> >        d) save faster

> I don't see these as major advantages.  As processor speed and over
> system speed in general increase, these will decrease.  Any major gain
> in these areas now will be lost on newer hardware.

Frankly, the problem _today_ has to do with neither of these, and will
not be solved by changing the way data is stored.

The problem that was had 8-odd years ago with CBB which continues today,
to some extent, with GnuCash is that the _display widget_ performs
increasingly poorly as the amount of data associated with the register
increases.

With CBB, that was the Tk "array" widget, where modifying anything
required recomputing the whole array, because it wasn't smart enough to
know to change just those bits that actually changed.  

With GnuCash, changing the date on a transaction could lead to a whole
cascade of data changes if that change moved a transaction from bottom
to top.  Every balance along the way could need recalculating, for
instance.
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linux.html
"Tools that are no good require more skill."