[thelist] pretty databases vs. fast databases

[Ken Schaefer]

"me too" posts aren't usually useful. But for people who are having doubts
about whether what Rudy is saying is good advice, I concur with everything
he says (if that help assuage any doubts).

Cheers
Ken

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "rudy" <r937 at interlog.com>
Subject: Re: [thelist] pretty databases vs. fast databases


: hi emma
:
: > left join cats_article on cats_article.article = meta_articles.id <--
: > allows multilingual content or content sorted by language
: > (one "article" can go into multiple categories/forums)
:
: be careful here
:
: when you join a "one" table, like the article table, with a "many" table,
: like article categories, the resulting rows will have the "one"
: columns repeated
:
: this is obvious, right?  it is the way a one-to-many query works
:
: however, it is disastrous when the "one" columns are large, as
: they would be with an article body, typically a large varchar
: or nvarchar or text or blob or what have you
:
: you really want to get the body only once per article
:
: this is a classic example of when it's better to split a query
:
: on the other hand, splitting imposes an overhead that may not
: be warranted by the actual data -- what if only one article in
: a hundred actually belongs to more than one category, while
: the rest all belong to only one?  then a single query is better,
: and you live with the idea of transmitting the body from the
: database to the frontend program multiple times, because it
: happens to a rare minority of articles
:
: > Here's my question: how do people feel about "wrecking"
: > database normalization and sticking (e.g.) author names
: > into the meta_comments table in addition to the author ID.
:
: well, i looked over your query, and it appears that this is already
: where the author name is coming from
:
: and no, i don't like "wrecking" normalization, as a general rule
:
: > It would reduce the query by one join.
:
: in general, this is not something you worry about in the design phase
: of a project, but rather in the load testing phase
:
: i'm being totally serious
:
: databases are designed to fulfill an information requirement
:
: design the relationships properly, and don't "wreck" any until you are
: forced to
:
: this will only be revealed in volume testing
:
: now, the advice i gave, about splitting a query into two, that has nothing
: to do with normalization, and, in general, those types of things *are*
: important to anticipate in the design phase of a project