[NCLUG] normalizing data

[J. Paul Reed]

On Sun, 6 Jan 2002, quent wrote:

> I would be tempted to stick with the first example, putting comments in
> the image table. It will save you from having to do a table join later,
> since a comment table by itself isn't usful, I suspect.

I actually recently built a database with separate comment and comment_text
tables; the comment_text table is really simple (commentid and comment),
and I guess the only reason I did it is because I'll often look at the data
directly via the CLI client, and having a blob/text type makes "select *"'s
look really ugly, especially when I so seldom need the actual comment.

It's probably a really crappy reason, and I do it because I'm too lazy to
say "select commentid, profid, grade, level, ques1, ques2, ques3 from foo"
every time I need a summary of something.

I suppose the join does take more CPU cycles, but I can't imagine that it
would be so prohibitive to do so... I mean, you're joining directly on a
primary key... but then again, I haven't taken database implementation yet,
so... what do I know? :-)

Mike: One thing I will say: I've found MySQL to be somewhat forgiving in
allowing you to modify tables later after they are in use. Having said
that, that's a database-specific feature, not a standard feature of the
database-ing field. That is, it does take some time to get a feel for
creating databases that are extensible without too much ass pain later
(which, admittedly, probably doesn't help you much; just build a couple of
databases with 200,000 records in 40 tables, and have your boss come tell
you "Oh, by the way..." and then you'll get a feel for how to build 'em...
:-)

Later,
Paul
    ------------------------------------------------------------------
    J. Paul Reed            preed at sigkill.com || web.sigkill.com/preed
    What's the point in being nuts if you can't have a little fun?
                                   -- John Nash, Jr., A Beautiful Mind