DB design document

[Rob Browning]

linas@linas.org writes:

> at some point or another, gnc-engine must convert whatever its doing
> to plain-old SQL statements.   The standard sql client side libraries
> just send these to the server via unix-dmoain sockets or tcp sockets.
> If its tcp sockets, you don't 'care' wheere the sql server is.  Think
> of it like using Xlib & getting xwindows network transparency
> 'automaticaly', with no extra work for the app writer.  Same idea. 

Yes, but, as an example, what if the SQL DB in question doesn't
support a rational number type, but we've decided that it's crucial to
do account balances on the server side (or imagine X other expensive
operation).

Since the server will be storing the rational numbers as a numerator
and denominator column, we *have* to have some of our code running on
the server side to make this efficient, and if you don't buy this
particular example, substitute another that you do buy.

In summary, I'm not talking about communication (though having
flexibility there may be a win too) I'm talking about being able to
have some say-so about where what operations should be physically
performed, no matter what a particular DB implements/expects.  For
fancy DB's our server-side proxy might be nothing more than a
"forwarder".  For dumb DB's it might have to implement some
number-crunching/caching of it's own.

This kind of flexibility also seems fairly crucial to being able to
customize systems to integrate with a given business' existing
infrastructure.  If they have a weak DB on the server, but they want
us to link to it, we could build a special version of our server-side
proxy that presents their database in the way we expect *efficiently*.

That's all I was suggesting.

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