[ic] Multiple ship to's...
Mon, 4 Dec 2000 09:08:23 -0500
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
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?
"Cameron B. Prince" wrote:
> 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
> 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,
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com]On Behalf Of Paul Stearns
> Sent: Sunday, December 03, 2000 8:01 PM
> To: firstname.lastname@example.org
> 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
> 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
> 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).
> Interchange-users mailing list
> Interchange-users mailing list