DB design document

[Dave Peticolas]

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 :)

dave