The same complex query, joining orders, customers, products and regions with several filter rules, has been copied into fifteen different reports. When a business rule changed, five reports were missed and now show different totals. What should the DBA do?
Select an answer to reveal the explanation.
Short Explanation
Fifteen copies of the same recipe means fifteen places to forget the new ingredient. Put the recipe in one place, a view, and have every report cook from it. An index makes your dish faster, but it does nothing for consistency.
Full Explanation
A view encapsulates query logic in a single named database object. When reports select from the view instead of embedding the joins and filters themselves, a change to a business rule is made once in the view definition and immediately applies to every report, eliminating inconsistent totals caused by divergent copies. Views also simplify report authoring, hide join complexity and provide a stable interface if underlying tables are later restructured. A covering index can speed up the joins, but it has no effect on where the logic lives; fifteen copies of the query would still need fifteen edits. Denormalizing the four tables into one wide table would reduce join complexity but introduces redundancy, update anomalies and a process to keep the wide table synchronized, and reports could still apply different filters to it, so consistency of business rules is not guaranteed. A shared document of query text is still copy-and-paste distribution; authors must remember to recopy after each change, which is exactly what failed. Exam caveat: views that join large tables still rely on underlying indexes for performance, and some engines offer materialized views that store results, which trade freshness for speed. Operational check: create the view with the current business rules, grant report accounts SELECT on it, repoint each report, compare totals across all fifteen reports, and keep the view definition in version control.