Question

I have a bridge table book_person between tables book and person to provide many-to-many relation. In this table I also have role-definitions, to set which roles (author, editor, illustrator, translator etc.) a person has on particular book. Now I consider to split roles to separate role tables (like book_author, book_translator etc). But I am in doubt, is it good idea or not? For pros, it makes DB more clean and one simple benefit I see that DBIC schema loader detects such simple bridge-tables and creates many-to-many accessors to me. For cons I see that aggregating functions for roles will need more joinings.

What are the benefits of using separate role-bridgetable over all-in-one role-bridgetable? And what are shortcomings? I am trying to upgrade my apps using ORM (DBIx::Class), but not knowing it well yet, so considerations towards it are also really welcome.

Was it helpful?

Solution

create table book (
  id_book integer primary key,
  name_book text,
  author_book
);

create table person (
  id_person integer primary key,
  name_person text
);

create table book_person (
  id_person integer,
  id_book integer,
  role_person text,
  primary key (id_person, id_book)
);

I think using role in book_person table is a good choice if one person has ONLY one role because:

  1. There are just a few roles which you use.
  2. To wouldn't to litter your DB when you could do it if created some more tables like book_author, book_translator.
  3. You don't need to use as you said many joinings.
  4. Roles in your case just an attribute and if you don't keep some extra info about roles capabilities you shouldn't create one more table for keeping binding role-person. You already keep it in book_person.

You need to create another table for role if you have:

  1. One person has more than one role.
  2. You keep some extra info about role as I said above.

I guess that's all.

OTHER TIPS

Given that a person can have multiple roles for a book, I would create a separate table (say book_person_role) with person-id/book-id as foreign key and a role-id. Thus you get a one-to-many relation from book_person to book_person_role. I wouldn't create a table per role; that would mean changing the schema when a role is added/deleted/changed.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top