XML size (was: no subject)
03 Apr 2002 20:52:15 -0500
Paul Lussier <firstname.lastname@example.org> 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.
SQL is far from inflexible....
> >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.
Not per se. They do transactional writes to the database, yes, but
that's not the same. If a crash occurs during a write, you will lose
that one transaction, not the whole file.
> > 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.
That's fine, you're allowed your opinion. Many other people (myself
included) consider speed a major issue. FWIW, this sounds like something
that would come out of Redmond: "Don't worry about the speed of our
software -- new machines will come out soon and it will work just fine"
One of the advantages of Linux has ALWAYS been that it runs much
faster than those other OSes on equivalent hardware. Simplicity.
> > 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?
Yes, because you don't need all the XML parsing and unparsing,
so you can "remove" that, and SQL is extremly small and concice.
So, yes, you are reducing size AND complexity by moving to SQL.
> As I said previously, the average home user isn't going to have so
> much data in their file that the size is going grow to such a state
> as to impact them or the performance of their system.
That's not what I've been hearing from other users that I've been
> I'll buy that argument for a business environment, but not for the
> home user.
Where is this line drawn? Besides, if we're going to do it for the
home-business environment, you'd just done all the work.
> >Note that I'm saying nothing about configuration files.
> And neither am I.
> >However, configuration != data.
> Ahm, everything is data, some is just accessed and used differently or
> more often than others.
I disagree. HOW the "data" is used is extremely important. But
perhaps we must agree to disagree.
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available