DB design document

[David Merrill]

On Thu, Dec 14, 2000 at 03:02:08PM -0800, Dave Peticolas wrote:
> David Merrill writes:
> > On Thu, Dec 14, 2000 at 12:11:35PM -0600, Bill Gribble wrote:
> > > On Thu, Dec 14, 2000 at 12:47:08PM -0500, David Merrill wrote:
> > > > Well this is a good time. As soon as I understand how they work
> > > > together I'll see how it might be achieved in the db.
> > > 
> > > It probably won't happen before you are finished with your first-round
> > > spec, so don't wait on that.  Just be aware that your database schema
> > > will probably have to change at some point in the future.  My guess is
> > > that it won't be a real holdup given the significant restructuring of
> > > much of the gnucash code that will be necessary to implement a
> > > database backend, anyway.
> > 
> > I disagree. One of the difficulties with databases is that it is much, much
> > harder to refactor that just about any other kind of programming.
> > We should make a valiant effort to establish an API and some table
> > structures that will stand the test of time right from the beginning. In some
> > cases we can put off coding against them until later.
> >
> > I want to implement the design cleanup along with the conversion to a databas
> > back end. Why refactor the client twice, and why refactor the db at all inste
> > of doing it right the first time?
> 
> That's fine, but the design cleanup will take time. There are more
> than just implementation choices involved -- the messy details of
> accounting rear their heads. The engine API for 2.0 isn't even
> finished yet, and there may *have* to be API changes after 2.0. I'm
> not trying to put the brakes on you, but right now you are designing
> to a moving target. Yes, from your point of view it would be nice if
> the engine design was all finished and perfected by now, but that's
> life :)

I am designing a SQL back end for storing financial data that is to a
large degree independent of the engine. In the same way that the
current architecture provides for a very clear separation of GUI and
engine, I am providing a very clear separation of engine and db.
Theoretically, some other project could reuse this database with
another engine, just as there could be a KDE client for the engine.

Obviously, I am designing specifically *for* gnucash, and not doing a
separate project. Considering it as a standalone entity is a
intellectual viewpoint that I believe will result in a better
database. It will make the system as a whole more robust.

Also, if it will be a long time before the rest of gnucash is ready to
use this database, then I have a long time to work on it!

:-D

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

The first time, it's a KLUDGE!
The second, a trick.
Later, it's a well-established technique!
		-- Mike Broido, Intermetrics