DB design document

linas@linas.org linas@linas.org
Wed, 20 Dec 2000 19:57:47 -0600 (CST)


It's been rumoured that Rob Browning said:
> 
> 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 ...
[...]
> ...and if you don't buy this
> particular example, substitute another that you do buy.

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.

I think we need much stronger positions as to why a gnc-server/cleint
split is needed.   That is not to say, there aren't any; I think
there are, e.g. maybe the multi-user and record-locking/update issues.
Maybe.   Even here, its not clear; we'd have to study up on the login
and authentication proceedures that sql db's offer.  It *might* be
enough to go full-bore multi-user.


> 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*.

Now, this is a whole-nuther-ball-o-wax.  

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.  Instead of having sql tables called 'account', 'transaction'
and 'split', there will be tables called 'customer', 'payment' and
'credit'.   The record field names will be equally wacky. The account
balances will be stored lord-knows-where.  How to map thier
data structures onto how we think the world should work?   This is
the fundamental problem of the lack of standards in accounting, and
is also why ERP is such a big deal.

--linas