JOIN conditions can be just as complicated as WHERE conditions, but overall having Play and Concert be totally separate things will bite you in the butt repeatedly in the future. The best structure for your database is something like this:
#! pesudocode Entity { id integer PRIMARY KEY, name varchar, ... } Play { id integer PRIMARY KEY REFERENCES Entity(id), director varchar, ... } Concert { id integer PRIMARY KEY REFERENCES Entity(id), start datetime, venue varchar, band varchar, ... } Comment { id integer PRIMARY KEY, entity integer REFERENCES Entity(id), comment_text varchar, ... }
If you need a list of concerts:
SELECT * FROM Concert c INNER JOIN Entity e ON c.id=e.id
If you need a list of plays:
SELECT * FROM Play p INNER JOIN Entity e ON p.id=e.id
If you need a list of comments on plays:
SELECT * FROM Comment k INNER JOIN Entity e ON k.entity=e.id INNER JOIN Play p ON k.entity=p.id
If you need a list of comments on everything:
SELECT * FROM Comment k INNER JOIN Entity e ON k.entity=e.id LEFT JOIN Play p ON k.entity=p.id LEFT JOIN Concert c ON k.entity=c.id
In the long run, you'll benefit a lot from factoring out as much of the common stuff between Concerts, Plays, Paintings, etc into a shared Entity table, then creating additional tables to store Concert-specific, Play-specific, Painting-specific, etc fields. I don't use DBIC, so can't offer specific advice on how to achieve it with that, but from a database design point of view, this is the better way to lay stuff out.
When you want to insert a new play, you insert it into the Entity table first to get its primary key number, then use that number when inserting the additional data into the Play table.
In reply to Re^3: DB: what kind of relationship?
by tobyink
in thread DB: what kind of relationship?
by bliako
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |