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".)
The fact that the former design is as consistent as it is should make it
relatively easy (intellectually) to "refactor" it in the few cases where
a mistake was made, even though implementing the change could be
tedious. The conversion should be a relatively easily executed
mechanical process. Provided the database is normalized in the first
place, it may not be necessary to "refactor" it at all except for
efficiency reasons. The new way of looking at it could be provided by
views.
>
> 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.
>
> 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.
>
> And just try adding a new constraint on a table where the data doesn't
> fit the new constraint.
That one is a toughie, but presumably does not happen all that often.
Can you suggest a constraint you would want to add that you would not
have thought of in the first place? I could imagine one that is
extremely unlikely to be added after the fact. Say you impose the
constraint that the overall assets of someone could never be negative,
and the person already has a mortgage and the value of the property
dropped significantly below the balance outstanding. Now if you try to
impose that constraint, it would fail of course. Now for GnuCash, I
doubt very much you would ever want to impose such a thing. I know in
Quicken, I write my estimated tax payments as soon as I know their
amount. If it even tried to insist my balance never went negative, I
could not do that, so I would hate the feature. If constraints
(especially new ones) are meant to prevent data entry errors, then
adding the constraint would just point out that data entry errors had
already been made, and they could not be corrected anyway. If the
constraints are to ensure integrety of the data, such as enforcement of
foreign keys, failures should be so bizarre that they will need manual
correction anyway, and at least this way you will find out about them
where otherwise they will just go unnoticed (which, though easier, is
not really a good way to go).
> On users' installations. Talk about nightmare
> installation scripts, and if one goes bad...
_____
* I do not wish to insult anyone's intelligence or anything, so let me
suggest that those not familiar with relational databases (such as those
with a SQL interface) might wish to consult a good book on the subject,
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
will not tell you the exact details of using any particular dbms
implementation, so you will need the manuals for your particular dbms,
but it will help with the more fundamental details of getting the basic
design correct so that "refactoring" should be needed far less often,
and it should be easier to do with less effect on developers (and,
ultimately, users).
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 73926.
/( )\ Shrewsbury, New Jersey
^^-^^ 7:45am up 11 days, 16:33, 2 users, load average: 2.15, 2.11, 1.88
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
