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.