Revisiting the database

Rob Browning rlb@cs.utexas.edu
10 Oct 2000 00:02:55 -0500


Christopher Browne <cbbrowne@localhost.brownes.org> writes:

> Very seriously, if you want to propose using a storage scheme that
> is _not_ readily embedded, you'd better have some _seriously good_
> ideas as to how to cope with implementing some sort of "DBA Druid"
> to walk naive users through the installation process.

Finally, I'm back to monitoring the list now (or at least I'm starting
back up), and here's my current take on the issue:

  1) I have finished the XML text file format, but it's not completely
     tested.  I should have a patch to Dave within a couple of days.

  2) The XML code has fairly serious performance problems right now,
     but I *think* these can be worked out.  However, even if they
     can't be, the current binary format is IMO effectively dead.  We
     *must* move to a richer file format to handle the new currencies,
     commodities, recurring transactions, numeric type, reports,
     etc. bits that we're either ready to add now, or are going to be
     writing/adding soon, and the XML code will address that problem
     *right now*.  If after a while, we still can't address the
     performance issues, then we'll do something different (see
     below), but we'll still be able to use the XML code as our text
     import/export mechanism.  (One bright note is that the XML
     format, when compression's turned on takes up *less* space than
     the binary format.)

  3) Regardless of whether or not the XML stuff works out for the
     single user file format.  It seems obvious to everyone that we
     will have to use SQL for anything of a larger scale.  That's
     fine, and we may even be able to use the new GNOME DBA stuff so
     that you can choose your own backend (PostgreSQL, MySQL, etc. -
     basically anything that you write the DBA communication layer
     for).

  4) I have spoken to both the MySQL and PostgreSQL developers about
     the possibility of an embedded version of their app and got two
     encouraging responses - to paraphrase:

       MySQL: "we already have a patch submitted to do that, and we
         just need to get a chance to audit it."

       PostgreSQL: "if you were willing to spend just a bit of time on
         the problem, it should be easy to hack up a solution that
         would work for a single user (or single app).  It wouldn't be
         much more than using the right command line options, and
         perhaps adding a little bit of socket code that would allow a
         dedicated copy of postgres to run in a little `sandbox'."

     This, of course, raises other interesting possibilities...

FWIW
-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930