Practice database schema review vocabulary: missing indexes, ambiguous column names, NOT NULL constraints, migration requirements, and schema approval language.
0 / 14 completed
1 / 14
A schema review comment says 'Missing index on the foreign key column.' Why is this a common schema issue?
Foreign key columns are frequently used in JOINs and WHERE clauses. Without an index, every such query requires a full table scan. Most databases do not automatically create indexes for foreign keys (unlike primary keys), making this one of the most common and impactful schema review findings.
2 / 14
A reviewer says 'The column name is ambiguous — rename to be explicit.' An example is renaming 'status' to 'order_status.' Why does this matter?
Ambiguous column names like 'status', 'type', or 'date' are common in schemas with many tables and cause confusion in multi-table queries. When reviewing a query using a generic 'status' column, it's unclear which entity's status it refers to. Explicit names improve readability and reduce bugs.
3 / 14
A schema review flags 'The nullable column should have a NOT NULL constraint.' When is this the correct recommendation?
Columns that should always have a value — foreign keys, required fields, audit timestamps — should be NOT NULL. Allowing NULL when a value should always exist leads to incomplete records that break application logic, produce incorrect aggregates, and require defensive null checks everywhere.
4 / 14
A reviewer says 'The schema change requires a migration.' What does a database migration involve?
A database migration is a version-controlled script that transforms an existing schema from one state to another. Migrations must be written carefully for production — considering backward compatibility (can old and new app code run simultaneously?), performance (large table changes under load), and rollback strategy.
5 / 14
A schema review ends with 'The reviewing engineer approved the schema design.' What does this approval typically confirm?
Schema approval in a review confirms the design is sound: data types are appropriate, constraints enforce business rules, indexes support expected query patterns, naming follows conventions, and the migration strategy is safe for the production environment. It is a quality gate, not a rubber stamp.
6 / 14
PR Description
During a code review, you receive this PR description:
"Schema update: Added `user_id` to the `orders` table. This allows us to efficiently retrieve order details by user. Consider adding an index on `user_id` for improved query performance."
This scenario highlights a common best practice in schema design – optimizing for query performance. While adding the `user_id` column is a good step, simply adding an index isn't always sufficient; it's crucial to understand *which* queries would benefit most. The correct answer acknowledges this nuanced approach, recognizing that indexing is valuable but needs careful consideration of the database schema and query patterns. Options A and D oversimplify the process, while option B correctly identifies the core purpose of the PR and the value of the index suggestion.
7 / 14
PR Description
During a code review, you receive this PR description:
"Schema update: Added `user_id` to the `orders` table. This allows us to efficiently retrieve order details by user. Consider adding an index on `user_id` for improved query performance."
This scenario highlights a common best practice in schema design – optimizing for query performance. While adding the `user_id` column is a good step, simply adding an index isn't always sufficient; it's crucial to understand *which* queries would benefit most. The correct answer acknowledges this nuanced approach, recognizing that indexing is valuable but needs careful consideration of the database schema and query patterns. Options A and D oversimplify the process, while option B correctly identifies the core purpose of the PR and the value of the index suggestion.
8 / 14
PR Description
During a code review, you receive this PR description:
"Schema update: Added `user_id` to the `orders` table. This allows us to efficiently retrieve order details by user. Consider adding an index on `user_id` for improved query performance."
This scenario highlights a common best practice in schema design – optimizing for query performance. While adding the `user_id` column is a good step, simply adding an index isn't always sufficient; it's crucial to understand *which* queries would benefit most. The correct answer acknowledges this nuanced approach, recognizing that indexing is valuable but needs careful consideration of the database schema and query patterns. Options A and D oversimplify the process, while option B correctly identifies the core purpose of the PR and the value of the index suggestion.
9 / 14
PR Description
During a code review, you receive this PR description:
"Schema update: Added `user_id` to the `orders` table. This allows us to efficiently retrieve order details by user. Consider adding an index on `user_id` for improved query performance."
This scenario highlights a common best practice in schema design – optimizing for query performance. While adding the `user_id` column is a good step, simply adding an index isn't always sufficient; it's crucial to understand *which* queries would benefit most. The correct answer acknowledges this nuanced approach, recognizing that indexing is valuable but needs careful consideration of the database schema and query patterns. Options A and D oversimplify the process, while option B correctly identifies the core purpose of the PR and the value of the index suggestion.
10 / 14
During a schema review for an e-commerce platform's `customers` table, a comment reads: 'Missing index on the foreign key column.' Why is this a common schema issue?
A. Indexes always increase database read performance regardless of their relationship to foreign keys.
B. Foreign key columns are inherently slow for querying due to the need to resolve relationships, and an index simply masks this inherent slowness.
C. Indexes on foreign key columns significantly improve query performance when joining tables, especially large joins involving these keys – they pre-calculate the relationship lookup.
D. Missing indexes are a symptom of poor database design, not a technical issue that needs addressing.
The correct answer is B because foreign key columns are often used in join operations. Without an index on the foreign key, the database has to perform a full table scan to find matching rows, which is extremely slow and inefficient. An index pre-sorts these values for fast lookup – failing to do so represents a significant performance bottleneck.
11 / 14
A reviewer suggests: 'The column name is ambiguous — rename to be explicit.' An example is renaming 'status' to 'order_status.' Why does this matter?
A. 'status' is a perfectly acceptable column name and doesn't require any changes based on best practices.
B. Ambiguous column names can lead to confusion for developers, making it difficult to understand the purpose of the data without consulting external documentation or asking questions.
C. The database system automatically resolves ambiguous column names and doesn't require any explicit renaming.
D. Changing column names is solely a cosmetic change with no impact on application logic.
The correct answer is B because clarity in data definitions is crucial for maintainability. An ambiguous name like 'status' doesn't clearly indicate *what* status it represents (e.g., order status, product status). This lack of explicitness can lead to misunderstandings and errors when developers query or update the data.
12 / 14
A schema review flags 'The nullable column should have a NOT NULL constraint.' When is this the correct recommendation?
A. A nullable column always needs a NOT NULL constraint to ensure data integrity.
B. A column that's guaranteed to always contain a value (e.g., an ID) should be marked as `NOT NULL` to prevent accidental null values and improve query optimization.
C. A nullable column *should* have a `NOT NULL` constraint only if the application logic explicitly prevents null values from being inserted or updated.
D. The decision of whether a column is nullable should always be based solely on the database system's default settings.
The correct answer is C because `NOT NULL` constraints enforce data integrity by preventing invalid data from entering the table. If the application doesn't explicitly prevent null values, a `NOT NULL` constraint isn't necessary and could even cause issues if the application *does* allow nulls.
13 / 14
A reviewer says 'The schema change requires a migration.' What does a database migration involve?
A. Database migrations are solely performed by the database system automatically without any developer intervention.
B. A database migration is a process of applying changes to the database schema – typically adding, modifying, or deleting tables and columns – in a controlled manner, often involving scripts that update the database.
C. Database migrations are simply renaming tables to ensure consistency across different environments.
D. Database migrations only apply when the application code is updated.
The correct answer is B because database migrations are a deliberate process of updating the schema based on changes in the application or business requirements. This typically involves running scripts that execute SQL commands to modify the database structure – it's not automatic.
14 / 14
A schema review ends with 'The reviewing engineer approved the schema design.' What does this approval typically confirm?
A. The reviewing engineer has completely verified that the schema is perfect and will never require further changes.
B. That the schema meets the current requirements based on the information available at the time of review, but doesn't guarantee it will remain suitable in the future.
C. The reviewing engineer has signed off on a completely untested and unvalidated schema design.
D. The approval is only valid if the schema change was implemented immediately.
The correct answer is B because an approval signifies that the design meets the immediate needs based on the available context. It's important to remember that requirements can evolve, and future changes may be needed – the approval doesn't represent a final, immutable state.
What does the "Schema Review Vocabulary" exercise practise?
Practice database schema review vocabulary: missing indexes, ambiguous column names, NOT NULL constraints, migration requirements, and schema approval language.
How many questions are in this exercise?
This exercise has 14 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Database Schema Design category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Schema Review Vocabulary" part of a larger series?
Yes — it's one exercise in the Database Schema Design category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Database Schema Design category page for related exercises, or browse the main Exercises hub for other IT English topics.