Naming conventions at scale in dbt - Step-by-Step Execution

Concept Flow - Naming conventions at scale

Define naming rules

↓

Apply rules to models

↓

Apply rules to sources

↓

Apply rules to tests

↓

Apply rules to snapshots

↓

Check for consistency

↓

Adjust rules if needed

↓

Scale naming across project

Start by defining clear naming rules, then apply them step-by-step to all dbt components, check consistency, adjust if needed, and scale across the project.

Execution Sample

dbt

version: 2

models:
  - name: stg_customers
    description: 'Staging table for customers'
    tests:
      - unique:
          column_name: customer_id

sources:
  - name: raw_customers

This snippet shows applying naming conventions to models, sources, and tests in dbt YAML config.

Execution Table

Step	Component	Naming Rule Applied	Name Example	Result/Output
1	Model	Prefix with 'stg_' for staging	stg_customers	Name set to 'stg_customers'
2	Source	Prefix with 'raw_' for raw data	raw_customers	Name set to 'raw_customers'
3	Test	Use descriptive test names	unique_customer_id	Test named 'unique_customer_id'
4	Snapshot	Prefix with 'snap_' for snapshots	snap_orders	Name set to 'snap_orders'
5	Consistency Check	Verify all names follow rules	All names checked	No violations found
6	Adjust Rules	Update prefix if needed	Change 'stg_' to 'stage_'	Rules updated
7	Scale Naming	Apply updated rules project-wide	All components renamed	Consistent naming across project
8	End	-	-	Naming conventions fully applied and consistent

💡 All components named consistently following defined conventions

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	Final
Model Names	undefined	stg_customers	stg_customers	stg_customers	stg_customers	stg_customers	stage_customers	stage_customers	stage_customers
Source Names	undefined	undefined	raw_customers	raw_customers	raw_customers	raw_customers	raw_customers	raw_customers	raw_customers
Test Names	undefined	undefined	undefined	unique_customer_id	unique_customer_id	unique_customer_id	unique_customer_id	unique_customer_id	unique_customer_id
Snapshot Names	undefined	undefined	undefined	undefined	snap_orders	snap_orders	snap_orders	snap_orders	snap_orders
Naming Rules	undefined	Defined	Defined	Defined	Defined	Checked	Updated	Applied	Finalized

Key Moments - 3 Insights

Why do we use prefixes like 'stg_' or 'raw_' in names?

Prefixes help quickly identify the type of data or component, making it easier to understand and manage large projects. See execution_table steps 1 and 2 where prefixes are applied.

What happens if naming rules are not consistent across the project?

Inconsistent naming causes confusion and errors when referencing components. Step 5 in execution_table shows checking for consistency to avoid this.

Can naming conventions change after initial setup?

Yes, step 6 shows adjusting rules if needed, then scaling changes project-wide in step 7 to keep consistency.

Visual Quiz - 3 Questions

Look at the execution_table at Step 3. What naming rule is applied to tests?

A Prefix with 'stg_'

B Prefix with 'raw_'

C Use descriptive test names

D Prefix with 'snap_'

💡 Hint

Check the 'Naming Rule Applied' column at Step 3 in execution_table

At which step does the naming convention get updated?

A Step 4

B Step 6

C Step 5

D Step 7

💡 Hint

Look for 'Adjust Rules' in the 'Step' column of execution_table

According to variable_tracker, what is the final name for the model after all steps?

A stage_customers

B raw_customers

C stg_customers

D snap_orders

💡 Hint

Check the 'Model Names' row in variable_tracker under 'Final' column

Concept Snapshot

Naming conventions at scale in dbt:
- Use clear prefixes like 'stg_' for staging, 'raw_' for sources
- Apply descriptive names for tests
- Check consistency regularly
- Adjust and scale naming rules project-wide
- Consistent names improve clarity and maintenance

Full Transcript

This visual execution shows how to apply naming conventions at scale in dbt projects. We start by defining naming rules such as prefixes for models, sources, tests, and snapshots. Then we apply these rules step-by-step to each component type. After applying, we check for consistency to ensure all names follow the rules. If needed, we adjust the naming rules and scale the changes across the entire project. The variable tracker shows how names change after each step. Key moments address why prefixes are important, the impact of inconsistent naming, and the possibility of updating conventions. The quiz tests understanding of naming rules applied at different steps and final naming outcomes. This approach helps keep large dbt projects organized and easy to understand.

Practice

1. Why is it important to use consistent prefixes like stg_, int_, and fct_ in dbt projects?

easy

A. They make the SQL code run faster.

B. They help organize models by their role, making the project easier to understand.

C. They automatically create indexes in the database.

D. They allow dbt to skip testing models.

Solution

1. Step 1: Understand the purpose of prefixes in dbt

   Prefixes like stg_ (staging), int_ (intermediate), and fct_ (fact) indicate the role of each model.

2. Step 2: Recognize how prefixes help in large projects

   Using these prefixes organizes models logically, making it easier to find and maintain them.

3. Final Answer:

   They help organize models by their role, making the project easier to understand. -> Option B

4. Quick Check:

   Consistent prefixes = better organization [OK]

Hint: Remember: prefixes show model roles clearly [OK]

Common Mistakes:

• Thinking prefixes affect performance
• Assuming prefixes create database indexes
• Believing prefixes skip tests

2. Which of the following is the correct way to name a staging model for customer data in dbt?

easy

A. stgCustomerData

B. StgCustomerData

C. STG_CUSTOMER_DATA

D. stg_customer_data

Solution

1. Step 1: Recall dbt naming style guidelines

   dbt recommends lowercase letters and underscores to separate words for readability.

2. Step 2: Evaluate each option

   stg_customer_data uses lowercase and underscores, matching the recommended style.

3. Final Answer:

   stg_customer_data -> Option D

4. Quick Check:

   Lowercase + underscores = correct naming [OK]

Hint: Use lowercase and underscores for dbt model names [OK]

Common Mistakes:

• Using uppercase letters
• Using camelCase instead of underscores
• Starting with uppercase letters

3. Given the following dbt model names, which one is a fact table according to naming conventions?

stg_orders
int_customer_info
fct_sales_summary
stg_products

medium

A. stg_orders

B. int_customer_info

C. fct_sales_summary

D. stg_products

Solution

1. Step 1: Identify prefixes and their meanings

   stg_ means staging, int_ means intermediate, fct_ means fact table.

2. Step 2: Match the prefix to the fact table

   Only fct_sales_summary starts with fct_, indicating a fact table.

3. Final Answer:

   fct_sales_summary -> Option C

4. Quick Check:

   Prefix fct_ = fact table [OK]

Hint: Fact tables start with fct_ prefix [OK]

Common Mistakes:

• Confusing staging and fact prefixes
• Ignoring prefix meanings
• Choosing intermediate models as fact tables

4. You see a dbt model named fct_customer_orders but it contains only raw data loading logic without aggregations. What is the likely issue?

medium

A. The model name prefix fct_ is incorrect for raw data; it should be stg_.

B. The model should be renamed to int_customer_orders because it is intermediate.

C. The model name is fine; raw data can be in fact tables.

D. The model should be deleted because it is redundant.

Solution

1. Step 1: Understand prefix meanings

   fct_ is for fact tables, which usually contain aggregated or transactional data, not raw loads.

2. Step 2: Match model content to prefix

   Since the model only loads raw data, stg_ (staging) prefix is more appropriate.

3. Final Answer:

   The model name prefix fct_ is incorrect for raw data; it should be stg_. -> Option A

4. Quick Check:

   Raw data = stg_ prefix [OK]

Hint: Match prefix to model content type [OK]

Common Mistakes:

• Assuming any prefix works for any model
• Thinking raw data belongs in fact tables
• Renaming without checking model logic

5. In a large dbt project, you want to create a naming convention that helps new team members quickly identify model types and their dependencies. Which approach best supports this goal?

hard

A. Use consistent prefixes like stg_, int_, fct_, keep names lowercase with underscores, and document the naming rules.

B. Use random prefixes for variety, mix uppercase and lowercase, and avoid documentation to encourage exploration.

C. Name all models with the project name prefix only, ignoring model roles and dependencies.

D. Use only numbers as prefixes to indicate model order, without descriptive names.

Solution

1. Step 1: Identify best practices for naming at scale

   Consistent prefixes and lowercase with underscores improve clarity and readability.

2. Step 2: Recognize importance of documentation

   Documenting naming rules helps new team members understand conventions and dependencies quickly.

3. Final Answer:

   Use consistent prefixes like stg_, int_, fct_, keep names lowercase with underscores, and document the naming rules. -> Option A

4. Quick Check:

   Consistency + documentation = easier onboarding [OK]

Hint: Combine clear prefixes with documentation [OK]

Common Mistakes:

• Ignoring documentation
• Using inconsistent naming styles
• Choosing unclear or numeric-only prefixes