Re: [tlug] database design idea... what do you think?

["Stephen J. Turnbull" <stephen@example.com>]

Stephen J. Turnbull writes:

 > Curt Sampson writes:
 > 
 >  > I've never seen a textbook that states this particular thing explicitly.
 > 
 > I have.  It's compost now.  Grows good apples.  :-)

In context, that was a bit harsh.  what I meant was that although it
takes a fair amount of practice to get the knack of applying the
various normalizations to your data, there's no excuse for a textbook
that gives simple, seductively inflexible examples.  I have seen such,
both in the database field and in several other areas as well.  But in
reality in this kind of design problem you have to step back and avoid
"textbook solutions"; they generally aren't what you want for the long
run.

By the way, the original proposal is actually quite similar to designs
that underlie some of the largescale web frameworks like Zope, also
the issue tracker Roundup uses something like it.  It's very nice for
"through-the-web" kaizen-ing of the schema, while allowing the backend
to be a powerful, efficient relational database like MySQL.  (Zope in
fact implements its OODB directly in the ZODB, but it feels quite
similar.)

On the other hand, these apparently very flexible designs have the
problem that because it seems like they should be able to do anything,
they just sort of grow.  But then they can hit a wall, where some
things are just impossible to do ... and others are harder than they
should be because the designer relied on flexibility to make up for
lack of documentation.

There just is no substitute for thinking ahead and designing your
systems based on the best theory available.