Is it wrong to have a database that can be interpreted in multiple ways [closed]

Question

I am creating a program to keep track of the production of a movie/show. Here is a screenshot (it's hi res PNG, so if you can't see it clearly, open in new tab)

You can have collaborators which are writers, directors, producers... who are all users. Then these users can collaborate on shows, or episodes within shows, or scenes. The problem is that I intend for this to be used as a way around enums. So I want a collaborator to be one of either a writer, a director, producer, photographer, or videographer. The bigger problem is that I want them to collaborate on only one project. Therefore, I would want them to collaborate on a single scene from an episode (ignore for a moment what constitutes 'collaboration'). Alternatively, I might want them to collaborate on the production of an entire episode instead of any particular scene. The plot looks even more counter-intuitive. It looks like a plot row points to all three scene, episode, and show, tables. Here too it is a way around using enums such that plot is only for the show, or the episode or the scene.

Should I go around making specific tables Show_Plot, Episode_plot and Scene_Plot, or is this fine?

Answer 1

There is no need to add any additional tables and increase the complexity of your data model when you can simply add constraints to your existing tables to enforce the behavior you require. I'm no MySQL pro, but I am sure that you can create function-based constraints to satisfy any schema restrictions you would need. This would also remove the problem of software-level constraints that might arise from multiple data-accessing applications (written by people other than you). Constraints remove any ambiguity about database use-cases like these.