[ic] Multiple ship to's...
Paul R Stearns
Wed, 06 Dec 2000 12:07:41 -0500
Thanks for your vote of confidence.
I was not specifically relating the normalization issue with my preference for
separate tables for separate purposes.
In the bad old days of Basic Plus on RSTS/E on a PDP 11, we only had 12 channels
on which we could open files. we regurlarly would design data structures where
we had multiple record types in a single file. As things moved forward I got
away from that practice.
I feel that an understandable data structure is more important than clever
programming, and nano/microsecond performance benefits. I would however
obfuscate my design if the application requirements demanded it.
Warren Odom wrote:
> Quoting Paul Stearns:
> >I would recomend against using 1 table for 2 purposes, such as ship to and
> bill to
> >in the same table but different records.
> >I also denormalize data when the needs of the application demand it.
> >I don't have a problem with an address table, but if you have one, don't
> >billing info in it.
> First, a technical point: After checking up to refresh my memory on
> normalization rules, it appears that a "unified" address table, even if some
> billing information is stored therein, does not violate first, second,
> third, or even fourth normal form. (This doesn't necessarily mean it's good
> to do it, however.)
> I actually have seen billing and shipping addresses combined like this into
> one table before, but it only makes sense if there are not too many fields
> that apply to one and not the other.
> After sleeping on this question, I find myself migrating to the other side
> of the fence and agreeing with Paul. Because of the "messiness" described
> in my original mail, I'd say keep shipping addresses in their own table
> unless there are compelling reasons to do otherwise. As Paul correctly
> notes, there are occasions when you have to break the rules, but the burden
> is on the rule-breaker to prove the cure won't be worse than the disease.
> -- Warren
> Interchange-users mailing list