Welcome to Working With Rails


Discussion Forums

Discuss all things Ruby on Rails with perhaps the web's most vibrant group of Ruby on Rails enthusiasts.
DB Design Question
3 Posts
DB Design Question

I'd suggest a RentalHistory model, where you can move the records to after they're returned. This will correctly identify them, as well as allow you to index it differently for searches and what-not, without unnecessarily slowing down the table of your active rentals.

Not that you should worry too much about performance so early (because you shouldn't), but honestly either method is fine. Just get 'er done. :)

Sorry about the strikeout on the lines above...please ignore. state is a field i was considering


I am developing a test application which will simulate a movie cataloging system in which you can lend movies to other users you are friends with. To do so i was going to have RentedMovies model with the following fields:

owner_id (user_id) library_movie_id (movie which is being lent out) borrower_id (user_id) --> user_id of who is borrowing the movie state --> [overdue, out, returned] due_date (datetime) --> due date for the movie returned_at created_at

I got hung up thinking about what to do when a movie is "returned". I would like to keep a history of rentals, so i was wondering if i should keep all the records in this table and just give them the state "returned", or if it would be better to create a 2nd tabled, returned_rentals or something, to keep the historical records of rentals?

Anybody have any suggestions? I'm wondering what advantages there might be in either approach. All suggestions are welcome and appreciated. Thanks!


3 Posts
Login to add your message