On 12 October 2014 11:34, Yongbiao Long <longyongb...@gmail.com> wrote: > On Sun, Oct 12, 2014 at 5:17 PM, Colin Law <clan...@gmail.com> wrote: >> Are you sure your basic design is appropriate? Having 100,000 >> associated records per user seems very high. Are you able to explain >> what is in those records in case an alternative can be suggested? > > Thank you Colin! I'm implementing a railway ticket-booking system just > for learn purpose, not for production. > Now I try to explain it: > Suppose a train has 20 stations along the way. It has 1000 seats to > sell. Table A store one train's information in a row. I want table B > to store every seat's information. I design table B as follow > > train_id: > start_city_id: > end_city_id: > seat_id: > availability: boolean type > date: > > For one train, the number of start_city_id and end_city_id's > combinations is 19+18+...+1=190, the number of possible date is > 20(people can book tickets in 20 days), and possible seat_id's number > is 1000. The total number of rows for one train is > 190*1000*20=3,800,000. So huge..
The first point is that you should only add rows as seats are booked, use that fact that there is no row to indicate that there is no booking. Secondly, what is the date? Is that the date of the journey or the date of the booking? I don't understand why you have multiplied the number of trains by 20 days. If it is the date of the journey then consider having a Journeys table which is a particular train on a particular day. Thirdly I don't understand why you have 20 factorial for the city combinations. Is it not true that if a seat is booked from station 1 to station 3 then that implies a booking 1 to 2 and 2 to 3? In which case you do not separate rows for bookings 1 to 2, 2 to 3, and 1 to 3. > > Actually I have more tables in database which are omitted as they are > unrelated. > > Maybe I should compute the state of any seat every time the system > issues a seat? (Some words on the state of a seat: A train goes by > city L, M, N, O and there is only one seat left. If a person has > booked M->N's seat, then L->O is not available, but L->M, N->O is.) > > -- > Best Regards > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-talk+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-talk@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rubyonrails-talk/CALDAArrOjR83tod-JgQ--ESvMJgu0ip7nGj6i0cQibjXS5qNWQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAL%3D0gLsXF428u1JXtxjg1exvK2U7j_W7E3-ExMoPCDQ%3D7bJ%2BwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
