Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 purchasing "tickets"

Author  Topic 

BitShift
Yak Posting Veteran

98 Posts

Posted - 2007-12-04 : 14:12:49
I want to enable my customers to purchase "tickets" that they can give their group who can then use when registering on my website, using the (prepaid) ticket number instead of paying. This way someone can buy a batch of these tickets and those numbers are reserved and once someone registers using that ticket number / id, then that number is no longer available. These tickets should be just like any other product, being added to a shopping cart etc, but once paid for the ticket # should be generated and should be unique to all other ticket#'s ever created.

ideas ? so far, Ive got the basic shopping cart and other product catalog part working, its just this idea of tickets that Im not sure how best to deal with. Here is a table im starting with

TicketID 4 int
SponsorUserID 4 int id of user who purchased ticket
OrderDate 11 datetime date ticket was purchased
FillDate 11 datetime date someone registered using this ticket
TicketNotes 12 varchar misc notes
TicketCode 12 varchar random and unique number


The basic idea here is that only once a successful payment has been made, is a Ticket record created. So if someone purchases 100 tickets, then this equates to 100 records.

ideas / suggestions welcome, thanks in advance



AndrewMurphy
Master Smack Fu Yak Hacker

2916 Posts

Posted - 2007-12-05 : 11:54:36
Can you prefill a tickets table with 'possible good tickets'....
and then you work towards using something like

select top 100 * from mytable where ticketidreservedbynotsoldyet order by newid (to select in random manner)
and run some process to 'reserved' them for x minutes....and before accepting the final order check that the reserved timeframe hasn't expired.
in the background you have a perpetual task looking for reserved tickets, which have not been bought after their reserved time frame...if 5/10 minutes or whatever you allow....and marking same available for selection back in the masterpool of tickets


also i presume you are putting in a check digit scheme to prevent people "inventing" their own ticket numbers!!!
Go to Top of Page

X002548
Not Just a Number

15586 Posts

Posted - 2007-12-05 : 12:36:32
why would you block tickets from potentioal clients by "reserving" them?

If they pay for them, then there off the market. Why limit your customer base?

What if they all get reserved and no one pays?



Brett

8-)

Hint: Want your questions answered fast? Follow the direction in this link
http://weblogs.sqlteam.com/brettk/archive/2005/05/25/5276.aspx

Add yourself!
http://www.frappr.com/sqlteam



Go to Top of Page

BitShift
Yak Posting Veteran

98 Posts

Posted - 2007-12-07 : 14:55:12
The idea is that they would not be "reserved" (or even created) until a valid payment has been made. In other words, during the checkout and payment, a process is done to generate ticket id's (some sort of random #) by using a random number and checking the tickets that have already been sold in the past. Its after that point, a user (who had the ticket purchased for them) can create an account, but instead of paying can use this ticket id to complete the registration. Thats why the ticket #'s need to be fairly hard to guess, but short enough not to make things too difficult for the user to enter.

Go to Top of Page

BitShift
Yak Posting Veteran

98 Posts

Posted - 2007-12-07 : 15:01:13
quote:
Originally posted by X002548

why would you block tickets from potentioal clients by "reserving" them?

If they pay for them, then there off the market. Why limit your customer base?

What if they all get reserved and no one pays?




See previous reply. Ticket ID's wouldnt get created until a valid payment is made. Then they are there until someone uses them during their registration process. Its after the purchase of the tickets that their ID's would be generated. When someone registers using that ticket id, its FillDate would be populated and no longer be available for others to use when registering. The idea would be for the purchasing user to give each potential user a separate ticket id or number, after completing the purchase.

Hope that was clear.

Go to Top of Page
   

- Advertisement -