No one designs a shopping cart system this way.
If you are dead set on this crazy design it doesn't matter if you put the
temp tables in the main database or another database. It'll be just as silly
On Wed, Jan 13, 2010 at 12:38 PM, Victor Subervi <victorsubervi@stripped>wrote:
> On Mon, Jan 11, 2010 at 3:21 PM, mos <mos99@stripped> wrote:
> > At 09:56 AM 1/11/2010, Johnny Withers wrote:
> >> Victor,
> >> The temporary table solution is not a good one. Use a single table and
> >> store
> >> 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
> >> "shoppers"
> >> 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
> >> (colors, sizes, etc).
> >> -JW
> > 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
> > later. Only delete it if there is no activity on it for 7-10 days. If
> > use temporary tables and throw out the shopping cart contents if the
> > 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
> 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?