[tlug] Re: Tlug Digest, Vol 25, Issue 14

["Micheal Cooper" <cooper.me@example.com>]

> ---------- Forwarded message ----------
> 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.

That is exactly why I was thinking of different solutions. Date's book
on Relational Databases makes it very clear that in order to have a
normalized database, any attribute of the data that might apply to
only one subset of the set needs a new table and a join table, but I
want to explore other solutions. There are quite  a few db folks who
say that fully normalizing a db makes it too complex and slow, that a
balance is needed between formal normailzation and ease of use.

> By the way, the original proposal is actually quite similar to designs
> that underlie some of the largescale web frameworks like Zope, also

Only after I submitted this post did I realize that. As I continued to
think about it, I wrote to a TLUG friend thought that it would be more
efficient to put the code that checks for probation and the code that
removes probation in the database itself. No need to keep a list of
students with probation status when you can have code in the database
that checks for you, and you can add attributes and checking code as
needed. You could have tables consisting of attributes and the code
that checks for those attributes.

And then I realized that this was really close to what I have heard
about Zope. I might be cowardly, but the Zope approach and the ZODB
really worry me. I like having a relational DBMS with a backdoor like
pgadmin, a big graphical schema on the wall, and good ole SQL there so
that I can fix things by hand if necessary. I like SQL a lot, in fact.
I find the Zope approach worrying, and that is why I am working my way
through the Django tutorial.

Now, to clarify my original post, I was suggesting this solution as
one table set in an otherwise normalized postgresql database because I
would only need one form for adding new attributes and associating
them with students. I was thinking of it as a way to add attributes to
students ad-hoc, but doing the entire thing with attribute-value pairs
would produce something structured like the Windows registry, if I am
not mistaken.

But after seeing everyone's comments, it does seem that making new
tables would be better, because I really do like the RDBMS cool-aid of
normalization. Hopefully, I can get comfortable enough with Python and
Django to remove the need to write forms by hand in PHP.

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

Too true.

-- 
Micheal Cooper
Miyazaki, Japan (GMT+9, no DST)