Question

My question might be dumb since I think it’s a very common design issue, and I guess there is a simple and usual solution to it:

• I have a table Producer and a table Movie
• ONE Producer has produced MANY Movies
• ONE Producer has ONE favorite Movie among the ones he has produced

How do I implement this in MySQL?

1. just one ONE-TO-MANY relation between Producer and Movie, plus a ‘favorite’ boolean attribute in the Movie table
2. one ONE-TO-MANY relation to represent the ‘has produced’ relation, and a ONE-TO-ONE relation to represent the ‘is favorite’ relation

The first solution seems more natural to me, but when the producer wants to change his favorite movie, I guess the second solution is more efficient. As well as it should be more efficient to find a producer’s favorite movie with solution #2.

What am I missing? Is there a best solution? If not in which case should I use solution #1 and solution #2?

(Of course, my problem is a bit more complex thant the example above…)

Answer 1

The (1) is not easy/efficient to enforce declaratively. Plus, you end-up wasting space on all non-favorite movies.

The (2) is the way to go. Unfortunately, this circular dependency will lead to the chicken-and-egg problem, which is solved:

• either by deferring one of the FKs (if the DBMS supports it, which MySQL unfortunately desn’t),
• or by leaving the FK in user NULL-able, which is less than ideal since the user can now have zero or one favorite movies (as opposed to strictly one).

---

Assuming you want the same movie to be relatable to multiple users (making it a many-to-many relationship, not one-to-many as you stated), your model would end-up looking something like this in a DBMS supporting deferrable FKs:

But you don’t have the luxury of deferring the constraints in MySQL, so you’ll be forced to do something like this:

CHECK (FAVORITE_USER_ID IS NULL OR FAVORITE_USER_ID = USER_ID)