Answer-first summary for fast verification
Answer: Create a new physical table with the updated schema for the application, then replace the original table name with a view that aliases the new table's fields to match the original schema.
### Why C is the Best Solution This approach leverages logical views to provide a **stable contract** for legacy consumers while allowing the physical schema to evolve. By creating a new physical table with the requested renames and additions, and then providing a view (using the old table name) that aliases those new fields back to their original names, existing queries continue to function without modification. This pattern is a best practice in Databricks for decoupling physical storage from logical presentation. ### Why Other Options are Less Ideal * **A**: Deep clones create a physical duplicate of the data, which increases storage costs and adds the operational burden of keeping the two tables synchronized. * **B**: Requiring all teams across an organization to update production queries is operationally risky, time-consuming, and creates significant friction. * **D**: While similar to C, replacing the original table with a view that points to a *different* logic while creating a new table for the app can lead to semantic confusion and doesn't necessarily minimize the number of objects to manage as effectively as building the view directly on top of the newly evolved table.
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
A data engineering team is managing high-impact aggregate tables used for BI dashboards, machine learning models, and customer-facing applications. One customer-facing application requires renaming several existing fields and adding new ones to a shared aggregate table.
Which strategy allows the team to implement these schema changes for the application while ensuring zero disruption to other downstream consumers and minimizing the management overhead of additional physical tables?
A
Use Delta Lake’s deep clone functionality to create a new table with the required schema and synchronize changes between the original and new tables.
B
Communicate the schema changes to all organizational stakeholders and provide a migration guide for updating legacy queries to the new field names.
C
Create a new physical table with the updated schema for the application, then replace the original table name with a view that aliases the new table's fields to match the original schema.
D
Replace the current table with a logical view that maintains the existing query logic and create a completely separate physical table to support the customer-facing application.