DB design document

[linas@linas.org]

It's been rumoured that Jean-David Beyer said:
> > More accurately
> > 
> > (sql server) || <- - - - - -> || (sql-client-lib <-> gnc_engine <-> ui)
> > 
> > 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.
> 
> OK in theory, but not the same in practice. If you use the IBM DB2 UDB,
> for example, the client-side library sends gawdawful stuff through the
> TCP/IP connection.

So what?  DB2 works over the network just fine.  Who cares what the
actual format is of the data that it sends?   

By analogy: very very very few X programmers ever really look at the
x-protocol or care what it is.  The xlib api sheilds ou from the wire
protocol.  Never mind that very very few people code straight X; most
use gtk, qt, motif, whatever.

> Here is an example of a tiny simple code fragment and how it was
> converted:

That's an example of sql embeded in C, which I always thought was
nasty way to code, but some people like that style.    There are 
other ways of talking sql with DB2.  Including, for example...
drum-roll..  odbc.


> Of course only the implementor of the dbms API as presented to the
> GnuCash developers needs to deal with any of this. 

Not even. If gnucash uses odbc, you need none of this.  And I think there
are better abstraction layers out there; e.g. I think geas loks
promising.


--linas