Using SQL, what is the best practice for designing tables that behave like interfaces for other tables?
<p>I'm trying to figure out what the best practices are for a situation I've encountered a few times over the past year.</p>

<p>To illustrate I've designed a fake database comprised of users, movies, and movies watched by users.</p>

<p><a href="https://i.stack.imgur.com/LjIrv.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/LjIrv.png" alt="enter image description here"></a></p>

<p>In this example, we want to be able to capture meta-data about any time a user watches a movie, like their location or the device they used, but the types of meta-data we may want to collect in the future may grow. The goal is to design a database that can aggregate many types of meta data for one movie watching experience.</p>

<p>So, I made a table called MovieWatchedMetaData to act like a bridge between different tables that contain meta-data. The premise is that this table will link the primary key from a meta data table like LocationWatched to a particular movie watching occasion.</p>

<p>I'm unsure about this approach and if it will be detrimental in the long run. Is this a poor practice? Is there a better, more appropriate way to accomplish this? How would you organize these tables?</p>