CQRS does not use a table per view, and a table per view is an aspect of the system that facilitates CQRS.
It is up to you and depends on your specific context and needs. I would look at this at the cost of the possible consistency of this request and the need for high query performance. You can consider the following two characteristics of your system:
1) Avg. consistency of this command, i.e. how long it takes to update all the reading models affected by this command (also consider whether the optimized stored-proc for change will exceed the value using ORM or another abstraction to update your database this way).
My guess is, if you do not say millions, for millions of records the consistency here is sufficient to satisfy your requirements and user expectations regarding the sequence, maybe a few seconds.
2) The importance of query performance. How many requests do you get per second? Can you handle the SQL connection every time?
In most practical scenarios, optimizing any of these things is controversial. Perhaps you can do the update regardless of the records using a good SP in seconds, which is more than enough consistency to update the interface (keep in mind that the user interface that issued this command can be consistent as soon as they know that the command is executed successfully).
And you usually don't need to scale queries so much on the system that a single connection will hurt you. What you might not need is the added internal complexity of doing these unions in your code and stored procs.
Like all things in CQRS, you do not need to use and optimize all its aspects from the first day. You can optimize these things gradually. Use connections today and completely deny tomorrow or vice versa.