[ic] Multiple ship to's...
Paul R Stearns
Tue, 05 Dec 2000 15:28:23 -0500
If you looked at the design I had originally specified, I recomended that we keep
the ship to address in the orderline table and the ship_addresses table, and
remove it from the userdb table and the transaction table.This gives the ability
to ship each line item to a separate individual ship to and gives the users the
ability to easily track there alternate ship to's.
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.
Mike Heins wrote:
> Quoting Warren Odom (email@example.com):
> >Quoting someone:
> > <<I am a firm believer in database normalization, and I hope that you're not
> > serious about moving the ship_addresses into the userdb table. In fact I
> > would like to see the current shipping info moved out of the userdb table
> > and into the ship_address table.>>
> > It depends on how this is done. We once had a prospect who needed to
> > support a large number of shipping addresses per order (like maybe 20 or
> > more). Trying to put these in one user record would not be wise. If,
> > however, Mike means that a shipping address will appear as a separate record
> > in the same table just like a billing address (which seems a more likely
> > interpretation), then I wouldn't necessarily call it a bad thing. You could
> > consider the table as an "address" table and I don't know that it would
> > really violate the spirit of normalization.
> I constantly violate the spirit of normalization. 8-)
> I am a firm believer in keeping down table proliferation, and changing
> the structure of a table is much harder to do than changing a stringified
> hash in a table.
> The userdb has had these address book features for years, but I
> have recently added support in the construct catalog for it. You
> can see an example if you go to
> and log in as the customer "ckirk" with pass "kirk".
> The problem with reading these from the db for purposes of storing
> in the order is that if the customer changes their ship address
> in the system the materiel could get mis-shipped. It needs to be
> attached to the transaction. I suppose it would be possible to create
> yet another table, or to deactivate records, or somesuch, but that
> seems rather ridiculous.
> Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH 45056
> phone +1.513.523.7621 fax 7501 <firstname.lastname@example.org>
> For a successful technology, reality must take precedence over public
> relations, for Nature cannot be fooled. -- Dick Feynman
> Interchange-users mailing list