5 exercises on database key phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
During a performance review, you notice a slow query is scanning every row in a million-record table instead of using an index. How do you describe this in a technical meeting?
"This query is doing a full table scan" is the precise database performance term for sequential reads across every row in a table — the most expensive query access pattern. A full table scan (also called a sequential scan in PostgreSQL) occurs when no suitable index exists or the query planner decides not to use one. This phrase immediately tells the team what is wrong and what the fix is: add an index or rewrite the query. Option A ("crashing") implies a system failure, not a performance issue. Option C ("overloaded") is vague. Option D ("broken") is imprecise. SQL EXPLAIN output will confirm a full table scan explicitly.
2 / 5
A colleague asks how to speed up a query that filters users by email and created_at on a table with 50 million rows. What is the professional recommendation?
"I'd add an index on those columns" is the standard database optimisation recommendation for filter-heavy queries on large tables. A composite index on (email, created_at) allows the database engine to jump directly to matching rows using a B-tree or hash structure, avoiding the full table scan. This is the first and most impactful performance lever in relational databases. Option A (rewriting in another language) does not change how the database executes the query. Option B (deleting rows) destroys data. Option C (moving the server) addresses hardware, not the query plan. Indexing is the correct first-line solution.
3 / 5
Your team is about to run a schema migration in production that drops a column. A senior engineer asks about safety. What is the most important thing to confirm first?
"The migration needs a rollback plan" is the correct priority for any destructive schema change in production. A rollback plan — typically a reverse migration script that restores the dropped column and its data — is essential risk management. Without it, a failed or incorrect migration can cause irreversible data loss. Option B ("will be fast") is a performance concern, secondary to safety. Option C ("no one will notice") is dangerously dismissive of impact. Option D ("no data in it") is a prerequisite check, but not a substitute for a rollback plan — even empty columns can have application code dependencies. Always plan for rollback before deploying schema changes.
4 / 5
You are writing a database operation that transfers funds between two accounts and must ensure both the debit and the credit either both succeed or both fail. Which statement describes the correct approach?
"We should run this in a transaction" is the correct answer for any operation requiring atomicity — the guarantee that multiple related writes either all succeed or all roll back together. Database transactions provide ACID guarantees: Atomicity, Consistency, Isolation, and Durability. A fund transfer is the textbook transaction example — if the debit succeeds but the credit fails, money disappears. Option A (two separate queries) has no atomicity guarantee and can leave the database in a corrupt state. Option B (stored procedure) could use a transaction internally, but the statement itself does not guarantee one. Option D (async queue) introduces delays and complicates rollback logic. Transactions are the standard solution.
5 / 5
Your team adds a new nullable column to a database table that is already in production. A developer asks if this will break existing API clients. Which statement correctly describes the safety of this change?
"The schema change is backward-compatible" is the correct technical description. A backward-compatible (or non-breaking) schema change is one that existing application code can continue to run against without modification. Adding a nullable column is the safest type of schema change: existing INSERT statements that do not reference the new column will succeed (the column receives NULL), and existing SELECT queries will still return valid results. Removing a column, renaming a column, or adding a NOT NULL column without a default are examples of breaking changes. Understanding this distinction is critical for zero-downtime deployments — always favour backward-compatible migrations that decouple schema changes from code deployments.