Re: Demo: Modelling Cost of Travel Paths Between Towns

"Hugo Kornelis" <hugo_at_pe_NO_rFact.in_SPAM_fo> wrote in message news:qs1dp0h29i85cutpisoavdp0toj91kklvs_at_4ax.com...
> On 13 Nov 2004 11:03:13 -0800, Neo wrote:
>
> (snip)
> >> Philadelphia PA 19104 6/1/1682 11/12/2004
> >> Neodelphia PA 19104 11/12/2004 12/31/2999
> >>
> >> And, no - storing PA twice is not redundant.
> >
> >Storing any thing (ie PA) twice is redundant.
>
> Hi Neo,
>
> A computer represents PA as a string of bits - either 16 or 32 bits on
> most modern computers. If you store PA twice, you have the same string of
> bits in two locations.
>
> If you store PA once, you'll have to replace PA in the above rows with a
> pointer to that location. A computer represents a pointer as a string of
> bits - either 16 or 32 bits on most modern computers. So even if you store
> PA once, you still end up with the same string of bits in two locations.
>
>
> > On way to prove
> >redundancy is to change the second PA and see if data is corrupted
> >(without triggers/code to synchronize them).
>
> Changes to the data should reflect changes in the reality. If PA state
> boundaries are changed at the same moment that Philadelphia is renamed to
> Neodelphia, changing the second PA would in fact even be required.
>
> Changing PA when the state boundaries don't change will of course trash
> your data, regardless of how you store it and how many times you store it.
> Even if I had just one row of data and then change PA to IL, it'll still
> be faulty.
>
>
> > Also, if a property is
> >added to PA, will you add it the first PA, second PA, or both?
>
> You are -once again- showing your total lack of comprehension of
> normalization. If a propert is added to PA, it should be added in a
> seperate table.
>
> Best, Hugo

Hugo,

Thanks. Saved me quite a bit of typing.

-Alan Received on Sun Nov 14 2004 - 06:09:20 CET