Views and tables

Materialization is a data decision

A view is a saved query and is right when the work is cheap and must stay fresh. A table stores a result and is right when work is expensive, reused, or latency-sensitive. The staging assets in this small project are cheap enough to be views.

Changing an existing DuckDB table to a view is also a warehouse change. Drop the old object before rerunning; --full-refresh does not replace an object's type. Incremental strategies exist, but their tradeoffs belong in the advanced course.

Your task

Choose exactly two staging assets and convert them to views. Validate, remove the old objects, rerun, and confirm their row counts are unchanged. Write a cost-or-freshness reason for each, then name one asset you would keep as a table and why.

Check your understanding

• Which two questions decide whether an asset should be a view or a table?
• A staging asset is a view. Nobody has run the pipeline in three days. What does querying that asset return?
• You change an asset from a table to a view and the run fails with Existing object ... is of type Table, trying to replace with type View. What happened, and what fixes it?
• Name two materialization strategies besides create+replace that update a table incrementally.

Do it with your agent

Say next lesson, make the two conversions, then say review my work. The agent should check that exactly two assets are views and that both reasons are about cost or freshness.