Cuestionario vinculado a una guía · Medio Nivel
Cómo depurar errores de SQL con AI Quiz
Practique el diagnóstico de errores de SQL, la agrupación de reparaciones y la verificación de resultados utilizando columnas ambiguas, esquemas modificados y pequeños dispositivos de prueba.
Pregunta 1 de 8
Two joined tables both contain id, and the intended output is the customer's identifier. Which repair addresses the ambiguity?
Vista previa de cada pregunta8 preguntas
Las respuestas y explicaciones aparecen a medida que realiza el cuestionario.
- Two joined tables both contain id, and the intended output is the customer's identifier. Which repair addresses the ambiguity?
- Qualify id with the customer table's alias
- Choose either id because matching names imply identical values
- Add every column to GROUP BY
- Rename the output heading without qualifying the reference
- Why can adding every selected column to GROUP BY be a poor repair for a customer-total report?
- It guarantees that all selected dates belong to the same customer summary
- It preserves customer-level totals regardless of the added columns
- It may change the result from one row per customer to a finer grouping
- It automatically chooses the latest order date within each customer
- An error points near the end of an expression. Why should earlier tokens also be inspected?
- The marked token must always be the first incorrect token
- Only the final clause can affect parsing near the end
- Name-resolution errors can always be fixed by moving the marked token
- An earlier missing comma or unmatched parenthesis can make a later token unexpected
- Which information is most useful when asking AI to reproduce an SQL failure?
- The query and a paraphrase of the error, without identifying the engine
- The engine, exact error, query, minimal schema and representative test rows
- Only a successful version from another database engine
- Only the expected output, without the query or schema
- A repaired SQL statement executes successfully. Which check still matters?
- Whether its rows, totals and null behavior match the intended result
- Whether it returns the same row count, without checking values
- Whether it has the same output headings, without checking totals
- Whether it runs once without an error on an empty fixture
- A cast succeeds for most rows but fails for one unexpected text value. Which debugging step targets that failure?
- Remove the type information from the prompt
- Assume the query is syntactically invalid in every context
- Include the failing value in a reduced test fixture
- Add an unrelated join to change the execution plan
- Why is PostgreSQL EXPLAIN ANALYZE inappropriate as a harmless syntax check for an untrusted modifying query?
- It never reports actual execution behavior
- It only checks table aliases
- It always skips the statement's write operations
- It actually executes the statement
- An application query uses bound parameters. Why should a reproduction preserve their types?
- Parameter types cannot affect a database operation
- Substituted literals can behave differently from the original bound values
- Every parameter should be converted to text before testing
- A bound parameter always removes the need to check casts