Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

table structure question

Status
Not open for further replies.

safra

Technical User
Jan 24, 2001
319
NL
I am new to working with tables. I do understand the basics , I just cannot come with the ideal structure of the tables in the project I am working on.

It is a database for a shopping cart for golf holidays where clients can book a car, ask for several availabality requests for property rentals and book several Tee times.

My thoughts are to set up 4 tables. one for client details, one for car rental, one for property and one for tee times.

What I cannot come up with is an efficient structure for those cases where people do more than 1 availability request for property or booked more than 1 tee time on golf courses.

Is it the best structure to apply an unique ordernr to each submission and put each individual, for example, tee time booking on a new entry in the table with the unique ordernr as the Key or is there a better way?

thanks,
Ron

 
i'd create only two tables. one would hold the client's details (each client will get a unique id) and the other will hold all of the orders (also each with unique id). be sure to have a field in the orders table that holds the id of the client who made the order and a field that will define what type of order (car, tee or property). this way you can query the orders table with a client id and get all of that client's orders.

unless each order (car,tee and property) has different fields this should work fine. if they have different structures from one another make three tables and add a client id to each one so you know which client made the order, and make the same query.
hope this helps :)
(-:
 
yes, each of the 3 booking options have different type of fields and a different number of fields.

So it is quite normal to use the structure I described and what you suggested.

thanks!
 
actually, I think I have to add another table for orders which include the client id and the unique ordernr. The other tables (except clients) will hold the ordernr.

This way I can maintain a clientdatabase for repeat orders. Am I right in this?

Sorry, this is not a very spectacular thread. Just want to start with this in the appropriate way an minimize the possibility that I have to change things in a later stage.

Ron

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top