CQRS - это не использование таблицы для просмотра, а таблица для просмотра - это аспект системы, который упрощает CQRS.
Это зависит от вас и зависит от вашего конкретного контекста и потребностей. Я бы посмотрел на это так, какова стоимость возможной согласованности этого запроса в сравнении с необходимостью высокой производительности запроса. Вы можете рассмотреть следующие две характеристики вашей системы:
1) Ср. согласованность этой команды, т. е. время, необходимое для обновления всех моделей чтения, затронутых этой командой (также подумайте, может ли оптимизированный сохраненный процесс для изменения превзойти, скажем, использование ORM или другой абстракции для обновления базы данных таким способом ).
Полагаю, что если вы не говорите миллионы, то при наличии миллионов записей согласованность здесь достаточна для удовлетворения ваших требований и ожиданий пользователей в отношении согласованности, возможно, нескольких секунд.
2) Важность производительности запросов. Сколько запросов вы получаете в секунду? Можете ли вы справиться с выполнением SQL-соединения каждый раз?
В большинстве практических сценариев оптимизация любой из этих вещей является спорной. Вероятно, вы можете выполнить обновление независимо от записей, используя хороший SP за считанные секунды, чего более чем достаточно для обновления пользовательского интерфейса (имейте в виду, что пользовательский интерфейс, выдавший команду, может быть согласованным, как только они узнают, что команда выполнена).
И вам обычно не нужно столько масштабирования запросов в системе, чтобы одно соединение повредило вас. Что вам может не понадобиться, так это дополнительная внутренняя сложность выполнения этих объединений в вашем коде и хранимых процессах.
Как и во всех вещах в CQRS, вам не нужно использовать и оптимизировать каждый его аспект с первого дня. Вы можете оптимизировать эти вещи постепенно. Используйте объединения сегодня и полностью денормализуйте завтра или наоборот.