Secondary Indexing Fundamentals in CouchDB Quiz

Explore the essentials of secondary indexing in CouchDB with this quiz, designed to evaluate your understanding of creating, querying, and optimizing views for efficient data retrieval. Strengthen your grasp of document-based database indexing concepts and best practices through scenario-based questions.

1. Purpose of Secondary Indexes

   What is the primary purpose of creating secondary indexes in CouchDB for your document database?

   1. To automatically back up the database
   2. To enable efficient querying on non-primary key fields
   3. To replace the need for primary keys
   4. To increase the document storage size

   Explanation: Secondary indexes are designed to allow quick queries on document fields other than the document’s unique identifier. They do not affect storage size significantly, nor do they replace primary keys. Automatic backup is unrelated to indexing, which is specifically about data retrieval speed.

2. Defining a Secondary Index

   How is a secondary index typically defined in CouchDB when you want to search documents by a 'status' field?

   1. By manually duplicating the 'status' field into each document ID
   2. By adding an index to the primary key field only
   3. By creating a map function in a design document that emits the 'status' value
   4. By renaming the database to 'status'

   Explanation: A map function in a design document emits key-value pairs for indexing, allowing secondary queries, such as searching by 'status'. Duplicating fields into the document ID or renaming the database does not create a secondary index. Indexing only the primary key cannot support searches on other fields.

3. Index Type for Efficient Searching

   Which type of index is commonly used in CouchDB to facilitate efficient searches based on custom document fields?

   1. Table scan
   2. Hash index
   3. Key lock
   4. View index

   Explanation: A view index is built from map and reduce functions, making searches based on custom document properties efficient. Hash index and key lock are terms from other database systems or have different uses, and a table scan does not involve any indexing, leading to slower queries.

4. Index Maintenance

   What happens to a CouchDB secondary index when documents are added, updated, or deleted?

   1. The index is automatically updated to reflect document changes
   2. The index ignores all changes until a full database restart
   3. No updates are applied unless the field is designated as a primary key
   4. The index must be deleted and recreated manually

   Explanation: CouchDB automatically updates its secondary indexes as documents change, ensuring the indexes remain consistent. Manual deletion or recreation is not needed, and waiting for a restart or requiring a primary key designation is not part of the indexing mechanism.

5. Map Function Output

   In a CouchDB secondary index, what does the map function typically emit when creating a view to index a document's 'type' field?

   1. emit(doc.type, null)
   2. emit(doc.id, doc.type)
   3. emit(type, id)
   4. emit(null, doc.type)

   Explanation: The correct pattern is to emit the field value as the key and often null for the value unless additional data is needed. Emitting null as the key, reversing arguments, or using undefined variables does not create the intended index.

6. Index Querying

   If you want to retrieve all documents where the 'category' field equals 'books', how would a secondary index help in CouchDB?

   1. It forces the engine to check every document without optimization
   2. It disables retrieving documents using 'category' as a filter
   3. It encrypts the 'category' field for security
   4. It allows retrieving relevant documents efficiently without scanning all documents

   Explanation: Secondary indexes provide efficient querying capabilities by avoiding full scans for filtering by indexed fields. They do not force inefficient searching, encrypt fields, or limit data retrieval based on indexed fields.

7. Updating an Index

   After modifying the map function in a CouchDB design document, what must occur for the secondary index (view) to reflect those changes?

   1. The map function must be reverted to its previous version
   2. A new primary key must be assigned to each document
   3. The view must be rebuilt the next time it is queried
   4. The entire database must be deleted

   Explanation: Views are rebuilt upon the next query after the map function is changed, automatically updating the index. Deleting the database or reverting the map function is unnecessary, and reassigning primary keys is unrelated to index rebuilding.

8. Composite Keys in Indexes

   Why would you emit a composite key, such as [doc.author, doc.date], in a CouchDB secondary index view?

   1. To reduce the size of the index by combining fields
   2. To encrypt author and date fields together
   3. Because single-field indexes are not allowed
   4. To support multi-field queries, such as filtering by author and sorting by date

   Explanation: Using composite keys enables multi-dimensional queries, such as retrieving documents for a specific author within a date range. This is not done to encrypt fields or save space, and single-field indexes are permitted.

9. Map-Reduce Views

   What is the primary advantage of including a reduce function in a CouchDB secondary index view?

   1. It allows for aggregation operations like counting or summing over indexed data
   2. It deletes duplicate fields within documents
   3. It doubles the number of documents returned
   4. It changes primary document keys automatically

   Explanation: Reduce functions aggregate values emitted by the map function, supporting operations like summing or counting. They do not increase document returns, remove duplicates at the document level, or alter document keys.

10. Limitation of Secondary Indexes

    Which of the following is a key limitation of secondary indexes in CouchDB compared to some relational databases?

    1. They cannot enforce uniqueness constraints on fields
    2. They encrypt every indexed field by default
    3. They are only available for numeric fields
    4. They automatically validate field data types

    Explanation: CouchDB secondary indexes do not enforce uniqueness on indexed values. They do not automatically validate data types, are not limited to numeric fields, and do not provide default encryption for indexed fields.