On Wed, 07 May 2008 07:55:48 -0400, Jerry Stuckle wrote:
> cvh@LE wrote:
>> @Jerry I absolutely agree with you on normalisation. And I, too, have
>> seldomly (although I do have) experienced that normalization is a
>> performance downer.
>>
>> However, the application-database which makes use of this column-
>> containing-a-set problem is normalized already, except for this column
>> which happens to contain data similar to comments. Comments mostly are
>> formulated as sentences, which happens to be nothing more than an
>> ordered space separated set. This column contains exactly the same. I
>> doubt anybody would normalize a short one-sentence comment field in a
>> table holding, let's say, additional remarks (3NF) given as part of
>> responses (2NF) by respondents (1NF) in surveys.
>>
>
> Yes, I understand your design. But there are no functions to retrieve
> information form a set because the set itself violates 1NF. And if the
> database is normalized properly, there is no need.
>
> And yes, I would normalize such a field in such circumstances.

To generalize a bit off of what I think Jerry's saying is that since
your requirement to access parts of comments exists, then "comment"
isn't a discrete element anymore. "Foo-part of comment" becomes then the
discrete element and you must then define what each normal form looks
like in light of that discrete element in order to decide whether it's
normalized or not. For example, if all I care about is counts in a set
of users' mailboxes, a single email is a discrete element, and tracking
an ID for each email, and what user it belongs to is normalized enough
for the purpose. If I need to know how many emails are in each
conversation thread, and how many were sent only internally to this mail
system, then it's NOT normalized, even though the data I have to work
with hasn't changed at all.

--
The Write Many, Read Never drive. For those people that don't know
their system has a /dev/null already.
-- Rik Steenwinkel, singing the praises of 8mm Exabytes