Why might you use an SQL view specifically to hide certain columns from end users?

Introduction / Context:
Views are often used as a security and abstraction layer. By exposing only selected columns, you can present a minimal, business-friendly interface while protecting confidential attributes (such as salaries or personal identifiers).

Given Data / Assumptions:

• The base table contains both public and sensitive columns.
• Different user groups require different levels of access.
• The database supports GRANT permissions on views independently of base tables.

Concept / Approach:
Define a view that projects only non-sensitive columns (and optionally filters rows). Grant users access to the view, not the base table. This both simplifies query writing and prevents accidental exposure of confidential data.

Step-by-Step Solution:

Verification / Alternative check:
Audits and permissions show users can read from the view but cannot SELECT from base tables lacking grants.

Why Other Options Are Wrong:
Only simplification / only protection: Views can do both simultaneously.
Views do not hide columns: They do by projecting a subset.
Improve plans only: Plan quality is not the primary reason for views; abstraction and security are.

Common Pitfalls:
Granting base-table access inadvertently bypasses the view’s protections. Always enforce least privilege.

Final Answer:
To accomplish both simplification and protection of sensitive columns