🤔 Как хранить в БД объекты с иерархией наследования?

Столкнулся в тралеботе с необходимостью хранить разные типы вопросов:
 
Есть вопросы с вариантами ответов, а есть вопросы, на которые нужно просто написать правильный ответ. У обоих классов есть базовые свойства и отличаются они одним полем. Значит удобно будет отнаследоваться от базового класса.
 
Как такое хранить в базе? Нашел статью, где рассказывается, что такое можно делать на вьюхах. Мне как-то вьюхи не особо нравятся. Даже не знаю почему. Просто не люблю, когда есть какая-то сущность, которая по сути не совсем настоящая. Появляется то, что Дерек Комартен называет indirection (типа непрямолинейность или хз, как это перевести).
 
Короче, погуглил еще, как такое делается. И в Entity Framework используется самый простой и прямой подход – на всю иерархию одна таблица Table Per Hierarchy. И еще используется Table Per Type  и Table Per Concrete Type (которая по сути тот же Table Per Type только с улучшенной производительностью).
 
Сидел читал про это дело и вот что вычитал. Судя по ответам на StackOverflow никто не юзает вьюхи для того чтобы работать с иерархиями наследования. Ну или точнее это не первая польза от них.
 
Так что как будто выбор идет между двумя подходами.
 
❓ Если работали с такой иерархией, то поделитесь, пжлст, какой подход выбрали, и к чему в итоге привело – было удобно или появились какие-то подводные камни?