State the primary goal of physical database design: is it chiefly to achieve data processing efficiency (throughput and latency), or something else?

Introduction / Context:
Physical database design implements logical models on storage media. Its “north star” is performance within constraints of cost, availability, and integrity. Efficiency encompasses both query latency and overall throughput for the target workload.

Given Data / Assumptions:

• Workloads have SLAs around response time and concurrency.
• Resources (CPU, memory, I/O) are finite.
• Design levers: indexing, partitioning, compression, placement, caching, and file formats.

Concept / Approach:
By placing data to reduce random I/O, designing appropriate indexes, and aligning partitions with query predicates, DBAs achieve efficient execution plans. Efficiency supports business objectives: faster analytics, timely transactions, and reduced infrastructure costs.

Step-by-Step Solution:
Map logical entities to physical tables and files.Select indexes and materialized summaries to match access paths.Partition/cluster to exploit pruning and parallelism.Tune storage parameters (extent sizes, fillfactor, autogrowth policies).Validate via workload replay and monitoring.

Verification / Alternative check:
Benchmark representative queries/transactions; measure CPU, I/O, and elapsed time before/after design changes to verify efficiency gains.

Why Other Options Are Wrong:
“Aesthetics” (option b) is not an engineering objective. Maximizing redundancy (option c) hurts consistency and storage costs. Avoiding indexes (option d) ignores read performance. Storing spreadsheets in tables (option e) is irrelevant to physical design goals.

Common Pitfalls:
Overfitting design to current queries and neglecting future growth; ignoring maintenance (statistics, rebuilds); forgetting that write-heavy OLTP and read-heavy OLAP need different optimizations.

Final Answer:
Applies — the primary goal is data processing efficiency