Menu
Community /Pin to ProfileBookmark
@NogDogMay 18.2006 — #Start by designing your database, as that will underlie everything else.
Without knowing enough details to be sure, I might approach it something like this:
[u]event_description[/u]
event_id (primary key)
description
price
[etc.]
[u]event_instance[/u]
instance_id (primary key)
event_id (from event_description)
date
start_time
[u]seat[/u]
seat_id (primary key)
section_number
seat_number
[or whatever other fields would best describe each seat]
[u]transaction[/u]
transaction_id (primary key)
instance_id
customer_id
[other info you want to track for each sales transaction]
[u]trasaction_to_seat[/u]
transaction_id
instance_id
seat_id
[the combination of these three fields would be defined as unique]
When checking for seat availablity or recording which have been sold, the transaction and transaction_to_seat tables would be the tables you search/update (using the other tables to present related information to the user).
Again, this is just a preliminary design concept off the top of my head. Depending on the specifics of your requirements you may need to change it a little or a lot.
Ticket Ordering System
Ok, so here’s what I’m trying to do:
Setup a ticket ordering system that shows a map of the auditorium and all the seats that have been purchased already. I have the map of the auditorium almost ready to go, but I’m unsure as to how to go about implementing such a system. I need to store the information in a MySQL database as well.
Anyone have any ideas on how to go about doing this? I don’t even know how to get started ?.
Thanks for all your help,
Will ?
Sign in
to post a comment3 Comments(s) ↴
0
@NogDogMay 18.2006 — #Start by designing your database, as that will underlie everything else.Without knowing enough details to be sure, I might approach it something like this:
[u]event_description[/u]
event_id (primary key)
description
price
[etc.]
[u]event_instance[/u]
instance_id (primary key)
event_id (from event_description)
date
start_time
[u]seat[/u]
seat_id (primary key)
section_number
seat_number
[or whatever other fields would best describe each seat]
[u]transaction[/u]
transaction_id (primary key)
instance_id
customer_id
[other info you want to track for each sales transaction]
[u]trasaction_to_seat[/u]
transaction_id
instance_id
seat_id
[the combination of these three fields would be defined as unique]
When checking for seat availablity or recording which have been sold, the transaction and transaction_to_seat tables would be the tables you search/update (using the other tables to present related information to the user).
Again, this is just a preliminary design concept off the top of my head. Depending on the specifics of your requirements you may need to change it a little or a lot.