Question

i’m just starting to learn about database design. For my first project I made a simple blog with padrino and now I want something a bit more challenging for me.
Since I am somewhat of a book nut, my friends always ask me to borrow them books. So naturally I have a lot of books floating around at any given time.

Now I’d like to have an app that lets me keep track of the books, ie: Every friend has an »Account«, I have many »Books« and my friends can rent books for any given period of time.
But I’m not entirely sure how to model the associations between the different models.

class Friend
  include DataMapper::Resource

  property :id, Serial
  property :name, String
  property :surname, String

  has n, :loans
end

class Loan
  include DataMapper::Resource

  property :id, Serial
  property :started_at, Date
  property :returned_at, Date

  belongs_to :friend
  has n, :books
end

class Author
  include DataMapper::Resource

  property :id, Serial
  property :name, String
  property :surname, Integer

  has n, :books
end

class Book
  include DataMapper::Resource

  property :id, Serial
  property :title, String
  property :year, Integer
  property :returned, Boolean

  belongs_to :author
  belongs_to :loan
end

I’d appreciate it if you could tell me if I am on the right track with this design or maybe point me to resources that could help me.
How can I effectively manage a book being »gone« and then available again for renting?

Thanks

Answer 1

Your current datamodel is going to have one major flaw – that is, books must all be returned at the same time (well, not really, but is a Loan ‘returned_at’ when the first book comes back, or at the last one?).

There’s also a bit of a disconnect between Friend and Author – what happens if a friend becomes an author (or an author becomes a friend)? They’d end up in your database twice, which is a problem.

Here’s how I’d start your library database (which is what it is, even if you only loan to friends). I don’t know anything about datamapper, so these are table designs themselves.

Person
==========
id  -- autoincrement
fullname  -- varchar(128) - names are tricky, keep it simple here
nickname  -- varchar(15), nullable - optional

Book
=========
id  -- autoincrement
isbn  -- char(16) - check length, though
title  -- varchar(128) - this only works with single-language libraries
yearPublished  -- integer

Book_Author
=============
bookId  -- fk reference to book.id
authorId  -- fk reference to person.id

Subject
==========
id  -- autoincrement
subject  -- varchar(16)
description -- varchar(256)

Book_Subject
===============
bookId  -- fk reference to book.id
subjectId  -- fk reference to subject.id

Checkout
===============
id  -- autoincrement
occuredAt  -- timestamp, UTC if possible (or capture timezone)
bookId  -- fk reference to book.id
personId  -- fk reference to person.id

Checkin
==============
id  -- autoincrement
occuredAt  -- timestamp, UTC if possible (or capture timezone)
bookId  -- fk reference to book.id

You can then tell what books you currently have on hand by which books have a Checkin record later than all Checkout records.

---

EDIT:

To ‘batch’ checkouts/ins, replace Checkout/Checkin with the following versions:

Checkout
===============
id  -- autoincrement
occuredAt  -- timestamp, UTC if possible (or capture timezone)
personId  -- fk reference to person.id

Checkin 
============
id  -- autoincrement
occuredAt  -- timestamp, UTC if possible (or capture timezone)

Checkout_Book
==================
checkoutId  -- fk reference to Checkout.id
bookId  -- fk reference to Book.id

Checkin_Book
==================
checkinId  -- fk reference to Checkin.id
bookId  -- fk reference to Book.id

Note that you don’t want to just add the _Book tables – you’ll need to remove the fk reference from the transaction tables as well, or you risk some nasty duplicate entries.