[ic] Multiple ship to's...

[Paul R Stearns]

Mike:

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 (warren-odom@stenocall.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
>
>         http://bill.minivend.com/cgi-bin/construct
>
> 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 <heins@akopia.com>
>
> For a successful technology, reality must take precedence over public
> relations, for Nature cannot be fooled. -- Dick Feynman
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@www.minivend.com
> http://www.minivend.com/mailman/listinfo/interchange-users