XML size (was: no subject)

[Rob Browning]

Paul Lussier <plussier@mindspring.com> writes:

> 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.

That makes me feel even more strongly that we'd be better off with SQL
and a well specified API for accessing the tables -- if you have
something like an SQL server between the apps and the data, it's a
heck of a lot easier to make sure they don't clobber each other.

> 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.

A good DB makes sure this *never* happens.  If this happens with
postgres running on reiserfs, I suspect it would be considered an
important bug, though I don't know for sure how far along they are on
this front ATM.

> 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.

>>        e) reduce the amount of core RAM required by the application
>>        f) have all the code necessary to move to SQL server
>
> So you're reducing the size of the application by adding code?

Well, if you use SQL, you don't have to write your own indexing and
query system, from scratch, for example, you get hopefully really good
transactions, locking, B-tree indexes, save/restore, and query
infrastructure for free.  That *definitely* makes some things easier.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD