On Mon, Jan 11, 2010 at 3:21 PM, mos <mos99@stripped> wrote:
> At 09:56 AM 1/11/2010, Johnny Withers wrote:
>> The temporary table solution is not a good one. Use a single table and
>> each item put into a cart identified by the session ID of the user. A
>> process should clean out this table periodically since there are
>> that abandon carts from time to time.
>> The design of this table could be quite simple:
>> id - int auto_inc
>> session_id - varchar
>> added_dt - datetime
>> item_id - int
>> quantity - int
>> You could get more complicated depending in your need an item requirements
>> (colors, sizes, etc).
> I also agree with JW, a single table is better. Don't forget shoppers may
> spend 30 minutes of more filling up their shopping cart and may lose the
> connection to the site or have to exit without completing the order. You
> need to retain the registered user's shopping cart so he can go back to it
> later. Only delete it if there is no activity on it for 7-10 days. If you
> use temporary tables and throw out the shopping cart contents if the session
> is lost, then you will *iss off a lot of customers.
I don't see how a single table is a solution. Tables are not 3D data
structures. If they were, you'd be right! I need 2D to describe the
customer's data: cols (ID, quantity, options, etc) X products. How can I add
a third axis of custID??? No! Not possible.
I am using cookies and committing data to the temp tables every time the
customer puts something in the shopping cart.
Can someone please answer my question as to which is better, putting the
temp tables in a separate database or together with the 'workhorse' tables?