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 requirements
(colors, sizes, etc).
On Mon, Jan 11, 2010 at 9:30 AM, Victor Subervi <victorsubervi@stripped>wrote:
> On Mon, Jan 11, 2010 at 10:49 AM, Baron Schwartz <baron@stripped> wrote:
> > Victor,
> > > That strikes me as messy. Each tmp table has as many rows as necessary
> > for
> > > the products that are to be bough. To do as you say I would have to
> > create a
> > > table with a zillion rows to accommodate however many products I
> > *predict*
> > > buyers would buy. Therefore, I guess I should probably create a new
> > database
> > > so as to not make a mess of the main database.
> > You fundamentally misunderstand relational database design. I suggest
> > reading this book:
> LOL. Ok, I'll put it on my list. *In the meantime*, since I am reworking my
> database design for the shopping cart I just finished building and need to
> get this up __n_o_w__, what would your advice be?
> > Regards,
> > Baron
> > --
> > Baron Schwartz
> > Percona Inc: Services and Support for MySQL
> > http://www.percona.com/
> The Logos has come to bear