Это в основном зависит от того, насколько изменчивы данные, сколько их существует и как часто к ним обращаются.
Например, если отвеченные данные не сильно изменились, вы могли бы безопасно кешировать их некоторое время; но если оставшиеся без ответа данные сильно изменились (и чаще), то ваши потребности в кэшировании могут быть другими. Если это так, то маловероятно, что кэширование его как одного набора данных будет лучшим вариантом.
Хотя это не так уж и плохо - если расхождение не слишком велико, то, возможно, все будет в порядке.
Еще один момент, о котором стоит подумать, это как связаны данные. Если элементы часто задаваемых вопросов переключаются между ответом и отсутствием ответа, то имеет смысл кэшировать базовые данные как единое целое - в противном случае элементы будут разделены там, где вы хотите, чтобы они вместе.
В качестве альтернативы можно работать с данными в памяти и рассматривать базу данных как дополнение ...
Что я имею в виду? Ну, обычно пользователь нажимает «сохранить», это вызывает код, который сохраняется в БД; когда придет следующий пользователь, он вызовет вызов, который получит данные из БД. С точки зрения дизайна, БД является гражданином первого класса, все должны пройти через это, прежде чем кто-то еще заглянет. Альтернативой является создание проекта на основе данных, которые хранятся в памяти (BLL), а затем сохраняются возможно асинхронно) в БД. Это устраняет БД как узкое место, но дает вам новый набор проблем - например, что произойдет, если соединение с базой данных оборвется или сервер умрет с данными только в памяти?
Плюсы и минусы
- Получение всех данных за один вызов может быть быстрее (при меньшем количестве вызовов).
- Имеет смысл получать все данные одновременно, если они связаны.
- Гранулярность: данные, которые связаны и имеют аналогичную "кэшируемость", могут кэшироваться вместе, в противном случае вы можете захотеть хранить их в отдельных разделах кэша.