Shopping Cart Conundrum . . . .

Report · Nov 02, 2006

I'm writing a tour booking site which is, without going into the nitty
gritty, horribly complicated.(I thought hotel booking systems were bad
enough BUT this raises the bar somewhat!)

I'm not quite sure what to do - I potentially have up to +/- 450 bits
of information per tour being booked which needs to be shoved into an
itinerary, which I then need to hold, before passing it over for
charging.

From past experience I would assume one or two tours being booked at
any one time, with the possibility of no more than 6 or seven tours to
be made on any one booking. Which every way you look at it, it is
potentially quite a lot of information.

Should I just shove it all into a SQL DB table and be done with it, or
use a shopping cart?

I've been using Joe Scavitto's excellent UltraCartll for years but I
think this may be beyond it.

I think shoving it into a database would be easier, the cart more
server efficient.

Ideas anyone?

TIA!

--
Buzby
There's nothing more dangerous than a resourceful idiot

Report · Nov 05, 2006

I would think that using a database table would be a lot safer here for
three reasons. Firstly the standard cart uses sessions to hold the cart
which can time out. This is going to frustate the hell out of a customer if
the tours is as complicated as you suggest.

Secondly the variable is limited in the amount of data that is can hold.

In terms of server efficiency I doubt that there would be much of a
difference between the two methods if your code is well written.

--
Paul Whitham
Certified Dreamweaver MX2004 Professional
Adobe Community Expert - Dreamweaver

Valleybiz Internet Design
www.valleybiz.net

"Buzby" <gb@pumpupthe.net> wrote in message
news:eicnl0$gb5$1@forums.macromedia.com...
>
>
> I'm writing a tour booking site which is, without going into the nitty
> gritty, horribly complicated.(I thought hotel booking systems were bad
> enough BUT this raises the bar somewhat!)
>
> I'm not quite sure what to do - I potentially have up to +/- 450 bits
> of information per tour being booked which needs to be shoved into an
> itinerary, which I then need to hold, before passing it over for
> charging.
>
> From past experience I would assume one or two tours being booked at
> any one time, with the possibility of no more than 6 or seven tours to
> be made on any one booking. Which every way you look at it, it is
> potentially quite a lot of information.
>
> Should I just shove it all into a SQL DB table and be done with it, or
> use a shopping cart?
>
> I've been using Joe Scavitto's excellent UltraCartll for years but I
> think this may be beyond it.
>
> I think shoving it into a database would be easier, the cart more
> server efficient.
>
> Ideas anyone?
>
> TIA!
>
> --
> Buzby
> There's nothing more dangerous than a resourceful idiot