Materialized views / snapshots: Does the refresh cost depend on whether the snapshot is simple or complex?
-
AApplies — simple snapshots may fast-refresh; complex often require more work
-
BDoes not apply — refresh cost is unrelated to snapshot definition
-
CApplies only if replication is synchronous
-
DApplies only to OLTP systems
-
EApplies only when using bitmap indexes
Answer
Correct Answer: Applies — simple snapshots may fast-refresh; complex often require more work
Explanation
Introduction / Context:In many DBMSs, “snapshots” or materialized views can be refreshed incrementally or fully, and their definition influences refresh cost.
Given Data / Assumptions:
- Simple views (single-table or certain join/aggregation patterns) can track changes efficiently.
- Complex views (arbitrary joins, non-deterministic functions) may not qualify for incremental refresh.
- Systems may require logs or MV logs to support fast refresh.
Concept / Approach:Fast (incremental) refresh uses change data to update only affected rows, reducing cost. Complex definitions may force complete refresh, reading base tables and recomputing results, which is more expensive.
Step-by-Step Solution:Classify the snapshot as simple or complex based on DBMS rules.Check availability of change tracking (logs).Choose fast or complete refresh accordingly.Estimate cost: incremental is typically cheaper than full recompute.
Verification / Alternative check:DBMS documentation lists allowable constructs for fast refresh and their performance implications.
Why Other Options Are Wrong:Replication mode, OLTP/OLAP labels, or index type do not dictate refresh complexity alone.
Common Pitfalls:Assuming all materialized views can fast-refresh; overlooking required logging or constraints.
Final Answer:Applies — simple snapshots may fast-refresh; complex often require more work