After migrating an order system to a new database, users notice orders that reference customer IDs missing from the customer table, and some product descriptions are cut off midway. Which validation approach would have caught both issues before cutover?
Select an answer to reveal the explanation.
Short Explanation
Matching row counts is like counting suitcases off the plane without opening any of them. You need to check that every order points at a real customer and that every field arrived whole. That's referential integrity plus value comparison.
Full Explanation
Database validation after a migration confirms that data arrived complete, correct and consistent. Referential integrity checks find orphaned child rows, such as orders whose customer ID has no matching parent, often caused by load ordering, filtering or disabled foreign keys during the load. A data mapping review confirms that each source column maps to a target column of compatible type and length; a shorter target column explains truncated descriptions. Value comparisons, using checksums, sampled row-by-row diffs or aggregates per column, confirm content matches the source rather than only its volume. A stress test measures performance under load and would run happily against orphaned and truncated data. Rebuilding indexes reorganizes index structures but cannot recreate customer rows that were never loaded or restore characters that were cut off; indexes do not hold lost keys. A row-count comparison by itself is a useful first check but would pass in this scenario, because truncated rows still count and orphaned orders count the same as valid ones. Exam caveat: validation should happen both after a test migration and again after the production run. Operational check: run an anti-join from orders to customers expecting zero rows and compare maximum string lengths per column between source and target.