DB design document

David Merrill dmerrill@lupercalia.net
Thu, 14 Dec 2000 13:23:55 -0500


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 database
back end. Why refactor the client twice, and why refactor the db at all instead
of doing it right the first time?

Besides, I can't abide a kludge, and don't want to reimplement one in the db
just because shit happened in the current implementation. Hey, I've done
kludges. I know that sometimes it's the only option. But I won't do it unless
I have to!


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

we:
	The single most important word in the world.