You can also build an Ecto.Schema for a view (materialized or otherwise) and treat it like any other table. For example, if you have a system with a Game schema, you could have it has_one(:game_stats, GameStats) and have that schema backed by a view.
Refreshing a materialized view could be a nice job for a GenServer. For example, when relevant changes come in, send a message to the GenServer, which checks every N seconds to see if there are any changes since the last time and refreshes the view if there are. It would be harder to implement that kind of rate limiting if you refreshed it using a database trigger, and refreshing it too often could burden the database.
You can create a materialized view in a migration, you just have to do
execute("""
CREATE MATERIALIZED VIEW game_stats
AS
SELECT
-- ...
""")
The only way I know to update that later is to write a new migration where you drop the old one and create the new one - copy, paste, and edit from the prior migration.
