DB design document

[Rob Browning]

linas@linas.org writes:

> I don't think there are any.  Virtually all sql db's support a
> common basic set of functions, and its hard for me to think of a
> good example where gnucash would need/want to use something that
> wasn't standard.

Say we decide we need to always perform some particularly complex
computation on the server side, and this computation requires
manipulating our numeric values (I presume most would).  Say also that
the DB in question does *not* have support for rational numbers.  How
can you do that without our own server side code (which would
presumably combine the numerator and denominator columns efficiently,
compute the result, and send the answer to the gnucash client -- and
the alternative would be pumping all the relevant rows over to the
client so that the client can do the job)?  Maybe we don't care -- and
we just declare that all numeric computations will happen on the
client side -- but I'm still a little uncomfortable just hauling off
and making that assertion at this point.

Also note that there's no reason why the gnc-client and gnc-server,
should we decide we need them, couldn't use standard protocols to talk
to each other, if those protocols prove appropriate.  At points you've
sounded like you think having our own layer on the server side
automatically implies we're not going to use CORBA/RPC/whatever.
Maybe we do, maybe we don't.  That seems an orthogonal issue to me.

> The problem won't be that they have a weak db server.  The problem
> will be that thier data will be organized in a fundamentally
> different way.

I maintain it could be either, and either way, if we're going to try
and present a unified face for their data to gnucash, being able to
massage/merge the data on the server side before sending it on to
gnucash seems desirable.

Overall, although having a place we can put server-side code may be a
bad idea for other reasons, it certainly seems to give us a lot more
leverage to handle varying DB server capabilities and legacy data
integration (if we decide to try to do that) --- problems that seem
like they might be awkward or impossible to fix efficiently if we just
rely on "whatever the DB server can communicate directly".

But perhaps we'll have to just agree to disagree on this point and
revisit it later when we're closer to needing to resolve it.  It's
quite possible I'm not thinking of things that would make server-side
code a bad-idea(TM).

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