On Sat, Dec 16, 2000 at 08:17:22AM -0500, Jean-David Beyer wrote:
> David Merrill wrote:
> >
> > On Sat, Dec 16, 2000 at 02:15:21AM -0500, James LewisMoss wrote:
> > > >>>>> On Thu, 14 Dec 2000 13:23:55 -0500, David Merrill
><[EMAIL PROTECTED]> said:
> > >
> > > David> 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.
> > >
> > > David> I disagree. One of the difficulties with databases is that it
> > > David> is much, much harder to refactor that just about any other
> > > David> kind of programming. We should make a valiant effort to
> > >
> > > I'm not disagreeing, but I'm curious what in your mind makes it harder
> > > to refactor?
> >
> > I'm not sure I can tell you all the reasons it's harder, but I'll try
> > to give you an idea. From many years of client-server development, it
> > seems that refactoring the database has consistently been the most
> > painful, tedious aspect of any project.
>
> This can certainly be a problem, but if the person who has the role of
> database designer normalizes (preferably to at least 3BNF*) the database
> when designing it, the times you would want to change its basic design
> should be extremely few, since each table (relation) of the database
> should be set up to correspond to one entity or concept in the real
> world and since the real world should not be changing all that much, the
> need to change existing items in the database should not change all that
> much either. (It might be necessary to add new tables to correspond to
> new stuff in the real world that GnuCash is to handle, but that would
> not require "refactoring".)
True in principle, but not always in real life. I'm certainly *trying*
to get it "right the first time".
> > At my current job, for example, we have a full time dba whose sole job
> > is shuffling data in and out of tables, massaging it, and putting it
> > back into new tables when they have been refactored. Even a single
> > field name change requires this.
>
> These changes should be invisible to users and application developers
> who do not need the new features (whatever they might be), since views
> could provide the same API (for existing applications) as they had
> formerly.
Ideally, yes, but it doesn't always work that way.
> > With GnuCash developers working against cvs, they would all be doing
> > this crap. Can you imaging all of you having to shuttle your data
> > around like this? You folks would not like me much, I'm sure.
>
> I do not think all the developers should be allowed to redesign the
> database. This is the kind of thing that one person should do, because
> it needs a consistant point of view (like writing a good novel as
> contrasted to a newspaper which can be written by many). The designers
> of GnuCash should decide on the entities they will need to deal with,
> and the database designer should design a database to manage those. When
> the other designers change their minds on how they use those entities,
> the dbms designer can provide additional views of the data, add or
> delete indices, etc., but this need not concern the other designers.
That is why I am maintaining a design document, and I'll repeat the
URL for those who tuned in late:
http://www.lupercalia.net/schema.txt
instead of putting it into cvs. I am getting lots of feedback from
folks, and lots of help, but I am filtering everything to ensure a
consistent approach and a cohesive design.
Unfortunately, I do not set policy at my job.
Don't you know that is one of the big problems with enterprise
software design? It's all designed by committee!
> such as Chris Date's "An Introduction To Database Systems" (I have sixth
> edition, 1995) published by Addison Wesley, ISBN 0-201-54329-X. This
That's an excellent book; I have it, too. Much more on internal
mechanisms, query preprocessing and optimizing, and other interesting
stuff than most books widely available.
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project [EMAIL PROTECTED]
Collection Editor & Coordinator http://www.linuxdoc.org
Finger me for my public key
I who am the beauty of the green Earth,
And the white moon among the stars,
And the mysteries of the waters,
I call upon your soul
To arise and come unto me.
-- from The Charge of the Goddess, Doreen Valiente
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
