Множество сущностей, связанных с одной таблицей. Хорошо ли это?
Такой подход позволяет использовать сквозные ID и уменьшать количество связей в БД, не теряя целостности.
Например, не комментарии к фильмам, комментарии к  записям блога, комментарии к  товару в интернет магазине, комментарии в ленте пользователя, а иначе - "комментарии к записи базового типа".
Применение указанной тобой формы или, наоборот, нормализация её - это исходит из бизнес-требований. Структура таблиц следует из анализа предметной области, а не потому что "так правильно" или "так красивее". Если модель хранения подходит для конкретного применения - это хорошая модель. Зачастую моделей может быть несколько, приходится выбирать одну исходя из требований. Для реальных задач может даже пригодиться ненормализованные данные (JSON) хранить в реляционной базе. А вот если идеальная красивая понятная модель по третьей нормальной форме не способна реализовать потребность с учётом простоты, объёмов, надёжности, гибкости, быстроты - это никому не нужная модель.
С точки зрения объектно-ориентированного программирования - это как создать производный класс от родительского. Например, контрагенты - это либо физ лицо, либо юр лицо, но совсем не обязательно заводить под них две таблицы, можно обойтись одной, хотя в приложении такие сущности будут значительно отличаться.
Или вот ещё пример: в системе может быть пользователь (user), который вдруг может стать продавцом (supplier) или потребителем (customer). Их можно хранить в одной таблице (user = customer = supplier), если отличие - в каком-нибудь признаке "is_сustomer" и "is_supplier".
Если у них разные дополнительные атрибуты, например у продавца есть банковский счёт, а у покупателя - счёт в PayPal, у продавца - адрес хранения товара, а у покупателя - адрес доставки - то часть полей одной записи таблицы user используется для покупателя, а часть - для продавца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` - счёт покупателяСхема условная
Но можно в одной таблице хранить только общие поля, а в дополнительных таблицах дополнительные поля. Сквозной ID сохраняется, даже нормальные формы работают.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` - счёт покупателяСхема условная
Тут указано, что их надо связывать отношением "один-к-одному".
Вообще грань очень незаметна. В любом случае в сложной схеме то на одни, то на другие грабли приходится наступать. Тут сквозные ID и избыток колонок в записи, а тут лишние UNION или JOIN, чтобы собрать вместе в одном отчёте. Если этот отчёт потребуется :)
Хранение сущностей в одной таблице относится к теме "Наследование в реляционных моделях" (не могу точно найти определение). Можно дополнительно прочитать тут:
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/
Лучше сделать для каждой сущности отдельную таблицу. Различных свойств всегда будет больше, чем одинаковых. Легче добавлять/изменять/удалять поля/столбцы. Проще добавлять/удалять сами сущности. Плюс портянку из эксплорера БД в 100-200 столбцов не очень интересно смотреть и очень неудобно с ней работать.