Ипатьев

Понятно же, что человек просто использует термины не по назначению. А имеет в виду способ взаимодействия с клиентом.
Словом "mvc" он называет классический способ, при котором сервер отдает клиенту HTML (а не JSON).
А словом "api" - REST сервис, при котором сервер отдает клиенту как раз JSON.

И суть вопроса сводится именно к различию между этими двумя способами:
- когда сервер генерирует HTML на основе полученных из БД данных, и отдает его браузеру
- или когда в браузере выполняется программа на JS, которая запрашивает с сервера только данные, а потом на их основе генерирует HTML

Поскольку первый способ является, условно говоря, "классическим", то про него в вакансиях и не пишут особо. А второй, поскольку является относительно "новым", и требует наличия пары несложных скиллов в дополнение к классическому, его оговаривают отдельно.

При этом с точки зрения бэкенд программиста разницы принципиальной между этими способами нет.
Главное в программе - это её бизнес-логика. И уметь надо в первую очередь писать её.
А в каком формате отдавать данные в браузер - дело десятое. И выбирать между "mvc HTML" и "api REST" нет смысла - уметь надо и то и то.

Ну и, как уже объяснили, MVC - это совсем другое. Архитектура приложения. Причем она используется для любых приложений, независимо от типа отдаваемых данных. M и C в "api" приложениях используются в полный рост. Только V немного упрощается. при этом поскольку MVC подразумевается по умолчанию, то и писать её в вакансиях тоже особого смысла нет.

Ну, на основной вопрос уже ответили, а я освещу отдельную проблему, которая очень часто волнует умы юных падаванов.

когда лучше реляционную и нереляционную использовать?

Ответ на этот вопрос очень простой.
Нереляционная БД - это НЕ база данных.
А узкоспециализированное хранилище, которое может выполнять какую-то одну определенную функцию лучше, чем база данных. Это может быть кэширующий демон, или поисковый движок, или решение для аналитики, или какое-то подсобное хранилище для всякого мусора.

Как только осознаёшь этот простой факт, то всё сразу становится на место:
Если нужна база данных, то и использовать надо базу данных. Реляционную. Какую именно - в вашем случае не принципиально.

Если вдруг проект пройдет стадию "неясные идеи", и выльется во что-то практическое, и даже появится какая-то нагрузка, то можно будет начать думать про использование одного или нескольких подсобных хранилищ в дополнение к базе данных.

Уфф, 5 раз прочитал, пока понял. Второе.

Метод класса вписывается в класс который над которым осуществляют действие.
Собственно, определение класса - это "данные и методы для работы с ними". С ними. А не с данными чужих объектов.

Сущность Модератор в данном случае вообще не нужна, достаточно свойства в сущности Пользователь (кстати, откуда вы все берете этих "участников"? Участник бывает у события, а не у сущности. Вы же не говорите "участник 5А класса?")

Связей здесь должно быть значительно меньше.
Если модератор не упоминается ни в опросе, ни в добавленной книге, то и связи между ними никакой нет.
В текущей схеме должна быть только одна связь: опроса с прошедшим его пользователем. Одним из свойств опроса будет экземпляр класса Пользователь. Причем это касается класса РезультатОпроса, которого нет на диаграмме. А он должен быть. И вот он будет связан с классом Опрос.

Чего здесь не хватает - это интерфейса. Классов-контроллеров. Которые собственно эти методы и вызывают.
Какой-нибудь BookController.add(), который принимает, скажем, два объекта, Пользователь и Инпут, и проверяет, является ли пользователь модератором. И если да, то создает объект Book, и используя данные из инпута, вызывает Book.add()
И то же самое с опросами

Еще по-хорошему должен быть BookRepository. Потому что если книга умеет сама себя добавлять в хранилище, то это считается плохим тоном. Должен быть отдельный объект Хранилище Книг, в котором и будут методы добавления и поиска.

В таких условиях надо делать вытесняющий кэш.
Если при запросе нового файла выясняется, что для него нет места, то удаляется самый старый файл.

Хотя конечно непонятно, как это всё поможет в ситуации, когда заходят посмотреть сразу 20 разных событий.

Ну что вы как дети?
Каждый раз этот вечнозелёный вопрос обрастает гроздьями любопытных.
Спарсить весь интернет мы хочем, а научиться пользоваться одним поисковым сервисом - не можем.

Никак.