Salutations

[Rob Browning]

David Merrill <dmerrill@lupercalia.net> writes:

> I have been using gnucash for awhile now, and I'm interested in
> helping with the development. I've been following your conversation
> on rdbms, and I think I can help with that module.
> 
> I do Oracle programming and I'm pretty good with SQL and database
> design in general. I can read C and I can do some simple C programming,
> but my C is quite rusty from years of disuse. That's a situation I
> would be very happy to remedy, though.
> 
> Any pointers, suggestions, tip, etc. as to how and where I might get
> started would be greatly appreciated. Who, for instance, is already
> working in this area?

First of all, welcome.

ATM no one is actively working on this, but we consider it one of our
"critical path" items going forward over the next year.  I've thought
a little about it, mostly from the perspective of trying to decide if
it was feasible to just bite the bullet and move to a DB instead of
another native file format, but that's about it.  So I suspect that
the first order of business would be a substantial amount of
discussion just to try and figure out what we need and want.

Just off the top of my head, here are some issues:

  * Should we prefer PostgreSQL or MySQL?

  * Can we avoid worrying about that with careful design and by using
    Gnome DBA?

  * Can we embed one or the other of these databases (i.e. set it up
    to run an a playground/file/directory in the user's home
    directory) so that we can replace our current file format, even
    for single-users, with the DB, without them having to know
    anything about database administration?  I've spoken to both the
    PostgreSQL and MySQL camps, and they both claim embedding is now
    possible, but someone needs to try it and see what that means.

  * What should the DB look like (structure-wise)?  What types do we
    need, can we do everything with "standard" types, etc.?

  * Closely related to the above, where should the engine code/db
    boundaries be right-now?  in the long run?  This discussion will,
    at least on the long run side, have to include a discussion of how
    to handle multi-user and local vs remote performance issues.

  * How much can we take this in stages?  i.e. perhaps we can first
    design the database, and set up the SQL server to just be
    "offline" storage, i.e. we read in the data when we start up, and
    write it out when we quit, but it's not "live".  Then later we can
    make the integration tighter.  Would something like this even
    help?

Again thanks for the interest, and I hope this is the kind of feedback
you were looking for.

I figure you might also want a little more info about how/where the DB
would probably tie in to the code, but I thought I'd let you digest
this first :>

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