DB Design Question

Not sure if this is the best place to post this, but here goes:

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

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

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


create_table :movies do |t|
t.column “user_id”, :integer
t.column “rental_id” :integer
t.column “title”, :string
t.column “state”, :text

create_table :rentals do |t|
t.column “movie_id”, :integer
t.column “returned_at”, :datetime

#use created_at as “rented_as”
t.column “created_at”, :datetime

has_many :rentals

def last_rental
:conditions = [“movie_id = ?”, self.id],
:order => “created_at DESC”)

belongs_to :movie

#Then you can do:
movie = Movie.find(:first)

why did you add rental_id to movies? and my rentals also needs an
user_id to denote what user is borrowing the movie

Adam W. wrote:

why did you add rental_id to movies? and my rentals also needs an
user_id to denote what user is borrowing the movie

Of course there should be no rental_id in movies. And of course you’re
right that rentals also should have a user_id. Actually the user_id
should be in just in the rentals, not at the movies at all…

Really sorry about that. I think I’m just a bit too tiered to be allowed
to answer peopels questions.

No problem :slight_smile: I guess i should make sure my question is clear, adn that
is this:

Should i have two tables or one?

one table:
when a movie is returned, i simply change the state of the rental to

two table:
when a movie is returned, i could have a 2nd table that is
rental_history. I could create a new record in rental_history, and then
delete the record from rented_movies.

I’m just wondering if one approach is better than the other if anybody
has an opinion


On Jan 8, 8:47 am, Adam W. [email protected]

delete the record from rented_movies.
I gave a similar reply on another thread: Ideally, just because an
object changes state, it shouldn’t change its class. Similarly with a
database row: it shouldn’t change tables just because its state

Pragmatically, having one table makes it easier and faster to report
on all rentals and it will make your code simpler and less buggable.
The only reason I might use two tables is for speed, but that’s not an
issue for you yet.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs