you can also run a task that archives past dates to a duplicate table since you'll rarely need them. maybe you can keep 1 month data in the table that you're writing to. this way, you won't have to worry about the exponential growth of the table you're always accessing.
On Sun, Oct 12, 2014 at 7:12 PM, Colin Law <clan...@gmail.com> wrote: > On 12 October 2014 11:54, Colin Law <clan...@gmail.com> wrote: > > 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. > > In fact thinking further, I would probably turn the problem around and > have a bookings table, specifying the journey, the stations, and the > seat (or seats). > > Colin > > -- > 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%3D0gLv77Kt-sH6rw0djfqrkNUycnkTimEw6anNg_oZSg-YOYg%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- ------------------------------------------------------------- visit my blog at http://jimlabs.herokuapp.com -- 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/CAJ8y7Vf2ShaMFvah%2B0%3DWv%3DWqdrhWH_f5Zgi2bNLuL%3DHPziVOyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
