Starting a new query

Developer imports metadata from Snowflake, AltaSQL auto-generates a SELECT with all columns (no SELECT *). Developer edits the ready-to-run statement (rename, reorder, add expressions).

Developer creates a new .sql file and hand-writes the SELECT statement. Often starts by copy-pasting an old query and tweaking it.

Reusing logic

Build a new “View Definition” by copying an existing one—metadata drives new SELECTs. Names, comments, tags, and column logic are inherited automatically.

Copy-paste old SQL code into a new file, edit it. Consistency depends on discipline.

Adding documentation / comments

Add comments, tags, or business-friendly names directly in the repository. They flow into every generated SELECT and CREATE VIEW.

Add comments inside the SQL file. Not enforced, often skipped. No central source of truth.

Sharing queries with teammates

Share a Virtual View (a named, reusable SELECT). Teammates call it directly without re-copying code.

Push .sql file to repo. Teammates must clone repo and copy logic into their workflows.

Debugging errors

Generated SQL is always properly quoted, qualified, and syntactically valid. Developer focuses on logic, not syntax.

Debugging often means chasing down typos, missing commas, or inconsistent column naming.

Maintaining large libraries of queries

Queries are modular, metadata-driven, and easily reused. Developers can assemble SELECTs like building blocks.

Queries grow as many files with overlapping, inconsistent logic. Maintenance means manual review and refactoring.