DAA-C01 Question 232
Single answerApply naming conventions to data columns and queriesA data analyst team at a retail company is standardizing SQL used in Snowflake for shared dashboards and ad hoc analysis. They want column names and query aliases to be easy to read, portable across BI tools, and less likely to require quoted identifiers. A senior analyst reviews the following SELECT statement proposed for a published semantic view:
SELECT order_id AS "Order ID", customer_name AS CustomerName, total_amount AS TOTAL_AMOUNT, order_date AS "date", region_code AS region-code FROM sales.orders;
Which change would BEST align this query with recommended naming conventions for reusable analytical queries in Snowflake?
- A
Rename all aliases to uppercase with spaces, for example "ORDER ID" and "REGION CODE", so they match how Snowflake stores unquoted identifiers internally.
- B
Use consistent, unquoted snake_case aliases such as order_id, customer_name, total_amount, order_date, and region_code.
- C
Keep mixed styles because Snowflake preserves alias formatting automatically, so naming consistency has little practical impact.
- D
Use reserved words when quoted, such as "date", because quoted identifiers are preferred for published analytical queries.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to standardize aliases as consistent, unquoted snake_case names. In Snowflake, unquoted object identifiers are stored and resolved in uppercase but are case-insensitive to users, making them easier to reference than quoted identifiers, which are case-sensitive and must be matched exactly. For reusable analytical SQL, especially queries feeding dashboards, semantic layers, or shared views, teams generally avoid spaces, hyphens, mixed casing, and reserved words in aliases because these patterns often force quoting and reduce portability across tools. Snowflake documentation on identifiers and naming conventions supports avoiding unnecessary quoted identifiers and choosing clear, descriptive names that are easy to reference consistently.
- A. Incorrect.
Incorrect. Although Snowflake stores unquoted identifiers in uppercase internally, introducing spaces forces quoted identifiers, which reduces portability and increases the chance of case-sensitivity issues in downstream SQL and BI tools. Uppercase with spaces is generally less practical than a simple, consistent convention like unquoted snake_case.
- B. Correct.
Correct. Consistent, unquoted snake_case aliases improve readability, avoid unnecessary quoted identifiers, and work well across shared SQL, views, and BI tooling. In Snowflake, unquoted identifiers are case-insensitive, which makes names easier to reference consistently. Avoiding spaces, hyphens, and reserved words reduces friction when queries are reused.
- C. Incorrect.
Incorrect. In practice, mixed naming styles create confusion and maintenance problems. Snowflake does not make inconsistent naming harmless: quoted identifiers preserve case and special characters exactly, while unquoted identifiers are resolved case-insensitively. Mixing these styles can lead to avoidable errors and poor usability.
- D. Incorrect.
Incorrect. While quoted reserved words can be valid syntactically, they are not preferred for reusable analytical queries. Using a name like "date" can create ambiguity and require users to remember exact quoting and case. Best practice is to choose descriptive, non-reserved, unquoted aliases whenever possible.