Naming policies: some organizations require that applications never reference base table names directly (e.g., forcing use of views, synonyms, or APIs). Is that a legitimate stance?

Introduction / Context:Abstraction layers (views, synonyms, stored procedures, service APIs) decouple applications from physical table structures. Some organizations formalize this decoupling as a policy: applications must not reference base tables directly.

Given Data / Assumptions:

• Desire for schema evolution without breaking apps.
• Centralized security and auditing via controlled interfaces.
• Multiple consumers with differing needs.

Concept / Approach:The policy allows DBAs to alter physical schemas (split/merge tables, change indexes/partitions) while preserving stable virtual contracts to applications. Views can expose only approved columns and can implement row/column security. APIs or stored procedures can validate and enforce business rules.

Step-by-Step Solution:Create views or synonyms that present a stable logical schema.Grant privileges on these abstractions, not on base tables.Refactor base tables as needed; keep view contracts intact.Use versioned endpoints for breaking changes.

Verification / Alternative check:Enterprise patterns (data services, data virtualization) commonly rely on this approach to avoid tight coupling and to centralize security.

Why Other Options Are Wrong:Relational theory does not forbid indirection; it encourages logical independence. Limiting this to specific system types or dialects misses the architectural motivation.

Common Pitfalls:Overusing views can mask performance issues; ensure underlying indexes match exposed query patterns. Keep documentation and versioning clear.

Final Answer:Correct — some organizations deliberately prevent direct use of base table names by applications.