Comedy_Gaz

There is a online program available that will set up your database. Its in PCF #138.

Web Guru

I usually program my cart data into an array in memory therefore no pruning is required and you only need one table for orders linked to a user id. All my code is in CF but your welcome to have a gander

Pete

DazV

All my code is in CF too - but I thought a memory based array and session / user variables would be a little too resource hungry ?

I've never seen anyone use an array, opposed to a database to hold this info.

bashful

Won't a memory-based array be vulnerable to crashes?

I use a 'last-touched' field in what would be your 'orders' table, which is updated on each addition or modification. Then I can run a pruning routine every X hours which cleans out abandoned orders.

DazV

So do you think its prudent to keep the 'orders' table separate from the 'non-orders' table, despite the fact they share an identical structure ?

non-orders = people who browse, fill their cart but don't order
orders = as above but complete the order

-DV

Web Guru

It all depends on the amount of traffic you expect to have as to whether using a session based system is worthwhile. I wouldnt say it is any more vulnerable to crashing providing you keep all the session vars locked down and you have a server worth its salt. It will certainly perform a lot better than going to the database on every trip, however if your looking at clustering on multiple servers then dont use sessions.

If your going the database route then I would say use one table why duplicate data and transfer when you just need to set a flag. And like you say flush on a daily or hourly basis. Or if its a user based system keep them there so the user is reminded of his shopping cart forcing the user to delete and do the flush on a longer schedule.

GaryK

Daz

why not stick with

orders
ordered_items

your ordered_items has a foreign key into the orders table and just have a completed flag in the orders table? That way as long as you keep orders updated you dont need to do a join to get the status of *all* entered orders. I *always* store session info in the db but then most of the work is done using stored procs on the db server.

Gary

DazV

Cheers Gary.

GaryK

Daz,

ooops forgot to mention your orders table should contain only order header information - name address, date of order, completed flag, then your order lines table contains the actual stock items, code, description, quantity, price etc. course then you could add a stock table as well!!!

Cheers

Gary

DazV

Yep, don't worry Gary - I've already had that structure running before posting.

Just wanted to know the preferred way of doing it, which, as it turns out, is pretty much what I'm doing.

Thanks again,
-DV

boxst

Hello

If I design applications, normally have:

--------- .... -----------
| .......|\ ...| |
| Order .| ----| Customer |
|________|/ ...|__________|
.. |
.. |
. / \
--------- .... -----------
| Order |\ | |
| Detail | ----| Product .|
|________|/ .. |__________|

And use an array to store temporary data if I am not too worried about the user losing their order if the Session times out. Or the order record has the flag as mentioned about if I need a persistant cart (only useful if the user registers of course...).

Steve.


** Edited because HTML doesn't display multiple spaces .. annoying!! **

[Edited by boxst - 8/10/2002 6:35:05 PM]

DazV

How unique is CF's session.sessionID ?

For non-registered users, I'd store the sessionID in the cookie.
For registered users, I'd store their email address in the cookie.

Web Guru

Well its pretty unique!

When you turn session management on in CFAPPLICATION the CF engine issues two unique cookies to the client cfid and cftoken and allocates unique session structure to that combination and client as soon as you set a session.var! Such as <cfset session.userid = somequery.userid> dont forget to use cflock when dealing with session variables

DazV

I'm curious about sessionID's in CF as I'm already using them.

If the user isn't logged in the sessionID is passed to the orders table as a means of identification.

When the user is logged in, their customerID is passed to the orders table to supplement the sessionID already there.

What I don't want obviously, is any duplicated sessionID's.

The memory based shopping cart seems a little more bullet proof. Just commit it to the orders table when the user has fully identified themselves. At least you don't get anything messing up the orders table that way.



[Edited by DazV - 8/13/2002 4:57:30 PM]

DazV

Initially I thought I'd use a single pair of tables:

-orders
-ordered_items

People could browse without logging in, and the system would rely on a cookie containing their session_ID (which would be stored in the orders table)

If people filled their cart but didn't finally complete the order, redundant data would be left in both tables (to be pruned at a later date). The drawback being each table would contain a mix of both 'unordered' and 'completed order' items.

Would it be prudent to use 2 pairs of tables...

-non-orders
-non_ordered_items

-orders
-ordered_items

When a user completes an order, the order data would be copied across from the 1st pair of tables (non-orders), to the 2nd pair (orders). The advantage being, its a cleaner approach and reduces the risk of corrupted orders ?

Really, I'd just like someone's opinion who's been here before.

Thanks in advance,
-DV


[Edited by DazV - 8/9/2002 7:18:38 PM]