Salutations

[Rob Browning]

David Merrill <dmerrill@lupercalia.net> writes:

> Oh, is that similar to ODBC in that it abstracts the database behind
> an API through which you pass SQL? Maybe that answers my questions
> above?

Presuming my nebulous knowledge of what ODBC is is right, then yes.
Gnome DBA is an abstract interface to the SQL databases, and it
supports various backends.

> What would be the benefit? With relatively small datasets, there
> wouldn't be much, if any, speed gains, but only lots of memory
> use. It seems like overkill for many people, and since gnucash
> already has a working local storage mechanism...

Reasons in favor (off the top of my head):

  - one set of code to maintain.

  - possibly better memory use (since right now we read in the
    *entire* file into memory).

  - we're going to need transactions/logging/journaling/whatever (i.e.
    safety mechanisms) anyway, I suspect implementing that once with
    the help of a good DB would be a lot easier than writing a DB
    implementation *and* a hokey local version.

  - it's probably easier to solve the multi-user stuff once too, and
    this may be easier if we only have one storage model.

  - also it's not clear to me (though I'm no expert) that it has to be
    a lot slower than what we've been doing.  Especially if either
    MySQL or PostgreSQL get around to optimizing the embedded case.

> Plus, it adds another point of failure, along with more complexity, to
> the system. When the power is needed, fine, you have to accept the
> complexity, but when it's not needed it should be avoided.

Depending on how we implement it, I could also see it decreasing the
code complexity in some critical areas, but of course it's hard to
know what the overall effect would be.  As an example, much of the
file IO code would go away -- it would be much harder to get that
wrong.

Also, we're already doing "hand-hacked" stuff internally that a DB
would probably be much better at, and as our data-model gets richer
(especially as we move to support more
consulting/small-business/financial-analysis stuff) this is only going
to get uglier as we have to hand-hack GLib indices, and push around
GLists of all the data whenever we don't have a DB.

I'm not saying you're wrong, I'm just saying that I can see things
that a DB *might* make better across the board.

> Now, I don't know MySQL or PostgreSQL (yet), so there could be gotchas
> I don't know about, but I doubt it. I just read an article online
> today where a guy converted his MySQL database to PostgreSQL in a day
> with minimal coding required.

Sounds good.

> Definitely designing the database schema is a good place to start.
> That is database-independent work and isn't affected by other design
> decisions much if at all. I'll take a look at the XML and see how it
> might be mapped into a database.

OK, feel free to ask any questions you might have.  I suspect that
gnc_numeric and kvp_frame are going to be the two ugliest bits.  As
I've mentioned before, we may have to rethink these while considering
an SQL database.

> I have a feeling that the multi-user aspects are going to be the real
> problem areas. Designing the database won't be hard (I've done many
> financial apps in my time!), and writing SQL will be pretty
> straightforward (the engine does all the work, really).

I agree.

> That's the idea, anyway. :-D

Thanks much for the help.

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