943,712 Members | Top Members by Rank

Ad:
Nov 29th, 2008
0

rest. menu table design

Expand Post »
I have a busted five table design for a food item guest ticket . Here are the names(Actual) of those tables: GuestTicketType, GuestTicket, GuestTicketOrderCategory, GuestTicketOrder & GuestTicketPayment.
The incomplete(busted) design looks like this: guesttickettype has a field named guesttype, which is one of three guest types: dinein, takeout, delivery.
The guestticket table holds the personal info like the first and last name on the ticket and the relevant data. The guestticketordercategory holds an ordercategory field that uses 7 different food item options: pizza, subs, salads, beverages, desserts, sides and addons. My first inclination was to set the two pre-populated tables (guesttickettype and guestticketordercategory) to hang off the guestticket table and the guestticketorder table, respectively. Not sure if that works or not....
I don't know how to set the tables properly, however, i do know the end game. Each guest should have an order and a payment to each ticket. Does that make sense?
My question, then, is what is the best way to accomplish that, either with the present setup or some other variation based on your recommendation?
Thank you for much needed help!
Similar Threads
Reputation Points: 10
Solved Threads: 0
Newbie Poster
mikeistyke is offline Offline
3 posts
since Nov 2008
Nov 29th, 2008
0

Re: rest. menu table design

From what I can make from your description and table names, here are the fields I would use:

GuestTicket: ID, GuestTicketType (FK), Name, etc
GuestTicketOrder: ID, GuestTicket (FK), GuestTicketOrderCategory (FK)
GuestTicketPayment: ID, GuestTicket (FK), etc

Please note that this allows each ticket to have several Orders and several Payments. Another design that would work is the following:

GuestTicket: ID, GuestTicketType (FK), GuestTicketOrder (FK), GuestTicketPayment (FK), Name, etc
GuestTicketOrder: ID, GuestTicketOrderCategory (FK)
GuestTicketPayment: ID, etc

Please note that the second design allows each ticket to have only one order and only one payment. The design really comes down to what type of relationship you need between ticket, order and payment and the direction of the relationship. The most general case would be a many-to-many relationship, which I did not list.
Reputation Points: 27
Solved Threads: 29
Posting Whiz
timothybard is offline Offline
317 posts
since Mar 2007
Nov 30th, 2008
0

Re: rest. menu table design

Thank you, timothy. I fixed the design based on your advice. I'm hoping to complete the forms and populate the db using aspx across the internet.
Thanks again for your helpful post
Reputation Points: 10
Solved Threads: 0
Newbie Poster
mikeistyke is offline Offline
3 posts
since Nov 2008
Nov 30th, 2008
0

Re: rest. menu table design

I am just curious: which method did you end up using? Each of the methods I mentioned supports different requirements, i.e. each ticket only has one order, each ticket can have several orders, etc.
Reputation Points: 27
Solved Threads: 29
Posting Whiz
timothybard is offline Offline
317 posts
since Mar 2007
Nov 30th, 2008
0

Re: rest. menu table design

I used the first version. I apologize for not stating the entire specifics of my needs. I should have said this:
Each guest ticket can have more than one order item and of course more than one payment. A guest ticket that only supports a single order wouldn't clearly depict the actual ticket. The ticket would be fragmented using the second option and incoherent, would it not?
May I ask you if you thought the table names were coherent and clearly suited for the intended purpose? Did I leave anything out that should have been inlcuded?
Thanks again for your help.
Reputation Points: 10
Solved Threads: 0
Newbie Poster
mikeistyke is offline Offline
3 posts
since Nov 2008
Dec 1st, 2008
0

Re: rest. menu table design

Since each ticket needs to support more than one order as well as more than one payment, then the first option is the option you should use.

As far as the names of the tables, I think they worked well.
Reputation Points: 27
Solved Threads: 29
Posting Whiz
timothybard is offline Offline
317 posts
since Mar 2007

This thread is solved

Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Message:
Previous Thread in MS Access and FileMaker Pro Forum Timeline: Should Workers Get Paid for Bootup Time?
Next Thread in MS Access and FileMaker Pro Forum Timeline: SQL moving data error





About Us | Contact Us | Advertise | Acceptable Use Policy
Forum Index | Build Custom RSS Feed


Follow us on Twitter


© 2011 DaniWeb® LLC