How to handle a table schema with a new relationship subtype in an interviews scenario? I have a table of "interviews" and "interview reviews" for both the interviewer and the interviewee. When the project was started there was only the need for one type of review, which is shown below



But now we have added a new type of interview which would require different types of reviews based in the interview type. I have added a many to many (M:N) relationship to store the interview type, but I am stumped as to the best way to go about adding multiple review types...



One solution I thought of was to add another table for reviews with the many to one (M:1) relationship which would contain all the data for the new review type. This would mean that the application would have to conditionally look for the review based on the type of interview, and it would lead to blank columns for all the unused review types...

How would you go about structuring this?
My gut says that the schema is rapidly getting too complex.

Let's back up and think about "Entities" and "Relationships".

There are 2 main Entities:  People and Reviews.  See if it is not too clumsy to put Interviewers and Interviewees into the same People table.  If the columns are too different, then make 2 tables.  Ditto for Reviews.

Then provide the minimum number of Relationship tables -- but only when there are many:many relationships.  (Many:1 does not need an extra table.)  The "Interview" is likely to be a Relationship table, but have a few extra columns for when/where/how-long/type/etc.

Do not "over normalize".  For example, an Interview Type is probably one of a few keywords.  These could be implemented in an ENUM without needing an extra table.