Goal
Choose a workspace whose engine, version, schema scope, and object definitions match the target environment, so review can recognize the objects the SQL depends on.Prerequisites
Before choosing a workspace, confirm the target database engine, version, and default schema, and identify the tables, columns, constraints, and indexes the SQL references.Select a workspace
1
Identify the target environment
Confirm the database instance, database or schema, and whether the SQL targets development, test, or production.
2
Choose the closest workspace
Prefer a workspace whose engine, version, schema scope, and object definitions match the target.
3
Check metadata coverage
Confirm that referenced tables, views, columns, constraints, and indexes are present.
4
Check freshness
Refresh the workspace after recent DDL or index changes.
5
Set schema resolution
If the SQL uses unqualified names, align the default database or schema with the runtime session.
Reviews that benefit from metadata
Workspace metadata is especially important for:- validating tables, columns, and data types;
- checking primary keys, uniqueness, and nullability;
- recognizing existing indexes and evaluating index candidates;
- analyzing
SELECT *, implicit conversions, and join predicates; - resolving dependencies, ambiguous columns, and schema-qualified names;
- generating rewrite or optimization guidance based on object definitions.
Keep context aligned
Expected Result
With a matching workspace selected, review recognizes the referenced objects, and metadata-dependent findings such as index candidates become available.Context checklist
- Engine and version match the deployment target.
- Default database or schema reflects runtime resolution.
- The workspace contains the main referenced objects.
- Metadata includes recent structural changes.
- Any missing context is documented in the ticket description.