Indexing fundamentals: Assess this claim.\n“Indexes can usually be created for both primary keys and secondary (non-primary) keys.”

Introduction / Context:
Indexes speed up data retrieval by creating auxiliary structures that map key values to table rows. Most relational database management systems (RDBMS) support indexes on primary keys as well as on secondary (non-primary, non-unique) columns. This question checks your understanding of what columns may be indexed.

Given Data / Assumptions:

• Typical relational systems (PostgreSQL, SQL Server, Oracle, MySQL/InnoDB) are assumed.
• Primary keys are unique identifiers and are typically indexed automatically.
• Secondary columns may also be indexed to improve query performance.

Concept / Approach:
Primary keys get index support automatically (unique B-tree, hash, or other structures depending on the engine). Secondary keys—such as foreign keys, frequently searched attributes, or sort/group columns—can also have indexes created to reduce scan costs. While details like clustered vs. nonclustered, bitmap vs. B-tree, and partial indexes vary by vendor, the general principle that both primary and secondary keys may be indexed is universally true.

Step-by-Step Solution:

Verification / Alternative check:
Query plans typically show index seeks/scans on both primary and secondary indexes when predicates match indexed columns.

Why Other Options Are Wrong:

• Limiting to clustered or unique-only scenarios is inaccurate; non-unique secondary indexes are common.
• Partitioning is orthogonal; indexes exist with or without partitioning.

Common Pitfalls:
Over-indexing, redundant indexes, or ignoring write overhead; failing to include leading columns that match query predicates; misunderstanding composite index ordering.

Final Answer:
Correct