Many entities associated with one table. Is it good?

Question

C++ / C#

Various media are stored in the database, such as: movies, series (+ seasons, episodes), music (+ music groups, music albums, music tracks), etc.
All these media are stored in one table and are distinguished by the Type field. Each type of media has both the same properties and different ones. For example: a movie can have a duration, but, for example, a musical group does not have a duration.
Question: how best to work with such a table in the application? I have 2 options:
1. Make one shared media model and one repository.
2. Make your own model and set of repositories for each type of media. In this case, all this will be tied to one table.
Which option would you choose and why?

Answer 1

This approach allows you to use end-to-end IDs and reduce the number of links in the database without losing integrity.
For example, not comments on movies, comments on blog posts, comments on a product in an online store, comments on a user's feed, otherwise - "comments on a base type post".
Application of the form specified by you or, on the contrary, its normalization - it proceeds from business requirements. The structure of the tables follows from the analysis of the subject area, and not because "it's so right" or "it's so beautiful." If the storage model is suitable for a particular application, it is a good model. Often there can be several models, you have to choose one based on the requirements. For real tasks, it may even be useful to store non-normalized data (JSON) in a relational database. But if an ideal beautiful understandable model according to the third normal form is not able to realize the need, taking into account simplicity, volume, reliability, flexibility, speed - this is a model that no one needs.
From the point of view of object-oriented programming, this is how to create a derived class from the parent. For example, counterparties are either an individual or a legal entity, but it is not at all necessary to create two tables for them, you can get by with one, although such entities will differ significantly in the application.
Or here's another example: there may be a user (user) in the system, who can suddenly become a seller (supplier) or a consumer (customer). They can be stored in the same table (user = customer = supplier), if the difference is in some attribute "is_customer" and "is_supplier".
If they have different additional attributes, for example, the seller has a bank account, and the buyer has a PayPal account, the seller has an address for storing goods, and the buyer has a delivery address, then part of the fields of one record of the user table is used for the buyer, and part is for the seller

table `user`
  column `id` as primary key
  column `full_name` - общее поле
  column `is_supplier` - продавец
  column `is_customer` - покупатель
  column `shipping_address` - адрес доставки покупателя
  column `store_address` - адрес хранения продавца
  column `bank_account` - банковский счёт продавца
  column `paypal_account` - счёт покупателя

But you can store only common fields in one table, and additional fields in additional tables. The end-to-end ID is preserved, even normal forms work.

table `user`
  column `id` as primary key
  column `full_name` - общее поле
  column `is_supplier` - продавец
  column `is_customer` - покупатель

table `supplier`
  column `id` as primary key & foreign key to `user`:`id`
  column `shipping_address` - адрес доставки покупателя
  column `bank_account` - банковский счёт продавца

table `customer`
  column `id` as primary key & foreign key to `user`:`id`
  column `store_address` - адрес хранения продавца
  column `paypal_account` - счёт покупателя

It is indicated here that they should be connected in a one-to-one relationship.
In general, the line is very invisible. In any case, in a complex scheme, one or the other rake has to be stepped on. Here are end-to-end IDs and an excess of columns in the record, and here are extra UNION or JOIN to put together in one report. If this report is required :)
Storing entities in one table is related to the topic "Inheritance in relational models" (I can not find the exact definition). You can read more here:
www.sql.ru/forum/67152/nasledovanie-v-baze-dannyh
https://msdn.microsoft.com/ru-ru/library/bb531247.aspx
postgresql.ru.net/manual/ddl -inherit.html
https://habrahabr.ru/post/28023/
https://habrahabr.ru/post/322596/

Answer 2

It is better to make a separate table for each entity. There will always be more different properties than the same ones. Easier to add/change/delete fields/columns. It's easier to add/remove the entities themselves. Plus, a footcloth from a database explorer with 100-200 columns is not very interesting to look at and very inconvenient to work with.

Answer 3

1.
>> All these media are stored in the same table and distinguished by the Type field
By entering a type that distinguishes the data in the table, you define conditional logic. And this is a complication of the code!
2.
One table one entity! Don't skimp on tables unless there are good performance reasons for doing so.
3.
There are object-oriented databases that allow you to pull out common parts into an analogue of the "base class". Look this way.
This is IMHO. Based on how it would be easier for me to understand how everything works.