Re: A Normalization Question

From: D Guntermann <guntermann_at_hotmail.com>
Date: Fri, 9 Jul 2004 18:32:00 GMT
Message-ID: <I0LKto.1r6_at_news.boeing.com>


"VHarris001" <vharris001_at_aol.com> wrote in message news:20040709084350.29796.00001157_at_mb-m18.aol.com...
> Dan wrote:
>
> >
> >If I were to change the 'br' in 'brown' of the street name to 'cl', would
> >all other references to 'brown' associated with other "objects" reflect
this
> >update? How would you know one way or the other how the system should
> >behave without semantic considerations?
> Why would it ever be necessary to change the 'r' in brown?

Because this is what the user thinks he or she is doing....

If it was necessary
> to have another thing spelled 'clown,' shouldn't the correct approach be
to
> create the new thing 'clown' in the thing table and point to the new
'thing?'
>

Hey, you can do whatever you want under the covers. I believe, however, that you will have a lot of overhead in repointing the pointers across all instances of the "virtual value" to the correct grouping of pointers to characters. And the degree of uncertainty and ambiguity doesn't go away.

#sigh#. We use normalization as means to ensure that when multiple instances of the same thing (conceptually) used in different contexts are changed in some way (updated or deleted, or even inserted). We have assurances that those same things are all updated consistently. With "nth degree normalization," we lose visibility to things that are the same and therefore the related conceptually.

> > A user might want all strings of
> >'brown' changed to 'clown' and in other cases, only the name of the
object
> >he or she is altering.
> >
>
> If the change is a correction, just change the pointer to 'clown.' If the
> change is an update, one could simply add a new date/timestamp pointer to
> 'clown' that superceded the prior pointer. This would not only point to
the
> correct change, but leave a history to the update.

You must be a coder who loves to code. ;-) Go for it!
>
>
> V Harris
>

- Dan Received on Fri Jul 09 2004 - 20:32:00 CEST

Original text of this message