Difference Between Simple View and Complex View
In MySQL, views can be categorized into simple and complex based on their query structure and whether they can be updated.
Based on a single table.
Does not contain JOINs, GROUP BY, DISTINCT, UNION, or subqueries.
Usually updatable (INSERT, UPDATE, DELETE allowed).
Provides direct access to underlying table columns.
Easier to maintain and faster in performance.
Based on multiple tables or advanced SQL operations.
May include JOINs, GROUP BY, DISTINCT, UNION, or subqueries.
Usually NOT updatable due to derived or aggregated data.
Useful for reporting and abstraction of complex logic.
Performance may be slower because of complex calculations.
Suppose you need to expose only the email column from the users table to a reporting tool. How would you create a view, and would you consider it a simple or complex view?
If you add a new column to the underlying table, what happens to an existing simple view that selects *? How would you verify it still works?
You have a view that selects first_name and last_name from employees. If you query the view with a WHERE clause on salary, what does MySQL do under the hood?
Your team built a view that joins orders and customers and aggregates total spend per customer. It’s running slowly. Walk me through how you’d diagnose whether it’s a simple vs complex view issue.
We tried to add a GROUP BY to an existing simple view and got an error about non‑deterministic columns. Why did that happen, and how would you refactor the view?
During a deployment, a change to the products table broke a view that was used by several services. How would you determine if the view was simple or complex and decide the fix path?
Design a strategy for replacing a set of complex reporting views with a more maintainable solution that scales to billions of rows. What trade‑offs do you consider between materialized views, indexed views, and query rewriting?
Our analytics pipeline relies on a complex view that joins ten tables and uses window functions. Under heavy load, the view causes lock contention. How would you redesign it, and what role does view complexity play in your decision?
Explain how MySQL’s optimizer treats simple vs complex views differently, and how you’d use EXPLAIN to verify that a complex view isn’t causing a full table scan.
We are migrating a legacy monolith to microservices, and many services depend on a library of complex MySQL views. How would you approach refactoring or deprecating these views while ensuring backward compatibility?
At a large e‑commerce company, you need to decide whether to keep critical reporting logic in complex views or move it to an ELT pipeline. Discuss the long‑term architectural implications, including schema evolution, testing, and data latency.
Your organization wants to enforce a policy that all new views must be simple unless a documented performance case exists. How would you implement governance, tooling, and review processes to enforce this at scale?