[ic] Multiple ship to's...

[Mike Heins]

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