Existing SQL

How to Review and Update Existing SQL

Learn how to understand an existing query, review its structure, adjust output columns and update it as database requirements change.

What is the safest way to review and update existing SQL?

First identify the query purpose, output grain, source tables, joins, filters, grouping, calculations, and returned columns. Separate columns displayed in the final result from columns required for joins, filters, grouping, or sorting. Make one structural change at a time, then compare outputs and test the revised query in the target database.

Understand the query before editing it

Existing SQL often combines presentation logic with structural dependencies. A column may not need to appear in the final output but may still be required by a join, WHERE clause, GROUP BY, or ORDER BY.

  • Summarise what one result row represents.
  • List every table and alias used by the query.
  • Map each output column to its source or calculation.
  • Document join type and join columns for each connection.
  • Identify filters, grouping, sorting, common table expressions, and subqueries.

Remove output columns without breaking query logic

A field used only in the SELECT list can often be removed directly. If it is also used elsewhere, remove it from the final result while retaining the structural reference. For example, a sort column can remain in ORDER BY without being returned by many database systems.

Example: hide the sort field from the result
SELECT
    p.project_name,
    s.site_name,
    po.total_order_amount
FROM projects AS p
JOIN sites AS s
  ON s.site_id = p.site_id
LEFT JOIN purchase_orders AS po
  ON po.project_id = p.project_id
ORDER BY po.purchase_order_date DESC;
AI-generated SQL may contain errors. Review and test before use.

Add a table or new output field carefully

Confirm the relationship first

Identify the key columns, expected cardinality, and suitable join type before adding a table. A one-to-many join can change the grain of the result even when the SQL is syntactically valid.

Add only the fields the result needs

Avoid selecting every column from a newly joined table. Explicit output columns make dependencies easier to review and reduce unexpected changes when the schema evolves.

Recheck filters and aggregates

A filter on the newly added table can change which base rows remain. Aggregates may also increase if the new relationship duplicates existing rows.

Compare and test the revised result

For a separate explanation of unfamiliar logic, see how to explain SQL in plain English.

  • Compare output column names and data types.
  • Compare row counts and key aggregates with the original query.
  • Test edge cases such as missing related records and duplicate identifiers.
  • Inspect the execution plan when the change affects performance-sensitive logic.
  • Retain the original query until the updated version has been approved.

How SQL Mocker can help review and update SQL

Use Output Columns to trace returned fields, Review Schema and Update SQL to remove or hide columns, and Add from Database to extend the query with reviewed schema metadata.

Related guides

SQL explanation

How to Explain SQL in Plain English

Learn how to break a SQL query into its purpose, data flow, joins, filters, calculations and output columns.

Read guide

SQL generation

How to Select Tables and Review Joins in Generated SQL

Start with the tables you know are relevant, investigate disconnected tables, review bridge tables, and check the joins SQL Mocker generates.

Read guide

AI SQL generation

How to Generate SQL for Your Database Without Connecting It to AI

Use extracted schema metadata and natural-language questions to generate SQL tailored to your database without connecting it to AI.

Read guide