[ic] Multiple ship to's...

[Warren Odom]

<<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.

But there are some things to consider.  You still need to include a field to
tell which shipping addresses belong to each billing address.  All searches
for billing info in the table need to have code to ignore the non-billing
addresses (and vice versa).  Also there will be fields that are needed for
billing addresses but which will always be empty for shipping addresses.
Added together, these kinds of complications could make it messy enough to
justify separate tables.

But, you know, I thought the latest version of Interchange already supported
multiple ship-tos....?  Did I misread the announcement?

           -- Warren



-----Original Message-----
From:	interchange-users-admin@minivend.com
[mailto:interchange-users-admin@minivend.com] On Behalf Of Paul Stearns
Sent:	Monday, December 04, 2000 8:08 AM
To:	interchange-users@minivend.com
Subject:	Re: [ic] Multiple ship to's...

Cameron:

The answer of course is to sort by ship to's and handle the shipping the
same
way it currently does, assuming of course that it does some sort of
consolidation currently.

My design stated below doesn't show it but, 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.
I
am aware of the tradeoff's sometimes associated with normalization vs
performance, but in this case, I would think that a single keyed read to get
a
"ship to" would be inconsequential.

Is the problem that flat file searches are (would be) too slow? I would
think
that sacrificing normalization for flat file search speed would not be in
the
product's best interest. This of course is only my opinion.

What is the timing for this "almost complete rewrite" more or less? a week?
a
month? 6 months?

Paul

"Cameron B. Prince" wrote:

> Paul,
>
> I think you are headed in the right direction here and you solution is
> entirely feasible. I am not sure if you are using product weights to
> calculate shipping, but one thing you may not have considered is
dimentional
> weight.
>
> It will be easy to calculate a shipping amount for each line item in the
> basket and add this all together to determine the total shipping amount.
But
> what if two items are going to the same non-default address? These items
> could be put into the same box, which would at times be less expensive
than
> shipping them separately.
>
> I have spoken with Mike regarding this function and he has informed me
that
> he plans to move the information in ship_addresses tables to the userdb
> table to consolidate the data somewhat. There will also be other
> improvements to this function and sounds like an almost complete rewrite.
>
> I am not sure when this will be done, so if your schedule is tight, it
would
> most likely be best for you to continue on your current path.
>
> Good luck,
>
> Cameron
>
> -----Original Message-----
> From: interchange-users-admin@minivend.com
> [mailto:interchange-users-admin@minivend.com]On Behalf Of Paul Stearns
> Sent: Sunday, December 03, 2000 8:01 PM
> To: interchange-users@minivend.com
> Subject: [ic] Multiple ship to's...
>
> Has anyone handled multiple ship to's?
>
> My thoughts on how to do it are;
>
> Add the shipmode to the ship_addresses table, force valid country and
state
> on ship_addresses
> table using pull downs.
>
> Add all fields from the ship_addresses table to the orderline table and
> populate with the
> appropriate data at checkout time.
>
> Modify the shipping routine to use the shipping info from the orderline
> table instead of the
> transaction table, use the shipping field in orderline to store the
> individual line item
> shipping charge, keep the total in the transaction table.
>
> Modify the receipt print and e-mail line item section to order by ship to
> with applicable
> subtotals.
>
> If feeling overly energetic, rip the ship to info out of the userdb, and
> transaction table. The
> main purpose of this is to remove redundant data. It might muck with other
> stuff in the system,
> so I probably will take the chickenhearted approach, and leave it in.
>
> If somone has done something similar please let me know any hints.
>
> If this functionality is already in progress by Akopia, please let me know
> before I waste my
> energy.
>
> Lastly, I would be glad to share this code when done, but I really could
use
> some help in
> finding out where all the bodies are buried (boy would I like to have an
> entity relationship
> diagram, and some inline documentation in the code).
>
> Paul
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@www.minivend.com
> http://www.minivend.com/mailman/listinfo/interchange-users
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@www.minivend.com
> http://www.minivend.com/mailman/listinfo/interchange-users


_______________________________________________
Interchange-users mailing list
Interchange-users@www.minivend.com
http://www.minivend.com/mailman/listinfo/interchange-users