DAA-C01 Question 233
Single answerApply naming conventions to data columns and queriesA retail analytics team is standardizing SQL used in Snowflake for dashboards consumed by finance, marketing, and operations. They want naming conventions that reduce ambiguity when queries are reused in worksheets, views, and BI tools. A senior data analyst reviews the following proposed SELECT statement for a reporting view:
SELECT ORDER_ID, CUSTOMERID, ORDERDATE, SUM(TOTALAMOUNT) AS Total, COUNT(*) AS cnt, REGION AS R FROM SALES_FACT GROUP BY 1,2,3,6;
Which change would BEST align this query with maintainable naming-convention best practices for data columns and query outputs in Snowflake?
- A
Keep the query as written because Snowflake preserves object names and BI tools can rename fields later.
- B
Replace aliases with clear, descriptive, consistently formatted names such as customer_id, order_date, total_amount, order_count, and region_name, and use explicit GROUP BY column names instead of positional references.
- C
Convert every output column alias to double-quoted mixed-case names such as "CustomerId" and "OrderDate" so analysts must reference the exact intended capitalization.
- D
Shorten all aliases to 1-3 characters, such as cid, odt, amt, and reg, to reduce query length and improve execution performance.
Show answer and explanation
Correct answer: B
Explanation
The best answer is Option 2 because naming conventions for analytical SQL should prioritize clarity, consistency, and maintainability. In practice, this means using descriptive snake_case or another agreed team standard for output columns, avoiding vague aliases like Total or cnt, and preferring names that communicate business meaning. It also means avoiding positional GROUP BY references such as GROUP BY 1,2,3,6 when queries are intended for long-term reuse, since positional references become harder to maintain as SELECT lists evolve.
In Snowflake, identifier behavior matters: unquoted identifiers are stored and resolved in uppercase, while quoted identifiers are case-sensitive. Because of that, many teams avoid quoted mixed-case aliases unless there is a specific need. Snowflake documentation on identifiers and general SQL style best practices support using consistent, descriptive names that are easy to reference across worksheets, views, and BI tools. For analytics engineering and reporting use cases, the goal is understandable schema and query output rather than minimal typing.
- A. Incorrect.
This is incorrect. Although Snowflake supports quoted and unquoted identifiers, relying on downstream BI tools to rename unclear fields is not a strong naming-convention practice. Ambiguous names like Total, cnt, and R reduce readability and make reusable SQL artifacts such as views and shared queries harder to maintain.
- B. Correct.
This is correct. Clear, descriptive, and consistently formatted aliases improve readability and downstream usability. Names like customer_id, order_date, total_amount, order_count, and region_name make intent obvious. Replacing GROUP BY positional references with explicit columns or aliases also improves maintainability because the query is easier to review and less likely to break semantically when the SELECT list changes.
- C. Incorrect.
This is incorrect. Double-quoted mixed-case identifiers are valid in Snowflake, but forcing case-sensitive quoted identifiers often makes SQL harder to use because references must match exact casing. This does not solve the main issue of unclear and inconsistent naming, and it can introduce unnecessary friction in shared analytics workflows.
- D. Incorrect.
This is incorrect. Very short aliases may save a few characters, but they harm readability and do not provide a meaningful performance benefit in Snowflake query execution. Maintainable analytics SQL favors descriptive names over cryptic abbreviations, especially for shared reporting layers.