Using Your Project as Context to Set Up .dinorules
This guide shows how to leverage your existing dbt™ project files to create comprehensive .dinorules that reflect your team's established patterns and conventions.
Last updated
Was this helpful?
Was this helpful?
Project Context
- Domain: E-commerce analytics
- Data Stack: dbt™ with Snowflake
- Project Structure: source → staging → intermediate → marts hierarchy
SQL Formatting Standards (Based on Analyzed Files)
- Keywords: Always uppercase (SELECT, FROM, WHERE, etc.)
- Indentation: 4 spaces, no tabs
- Comma Style: Trailing commas in SELECT statements
- Aliasing: Always alias tables (use 'u' for users, 'o' for orders)
- CTEs: Prefer CTEs over subqueries for readability
- Comments: Add comments for complex business logic
Naming Conventions (Extracted from Current Models)
- Models: snake_case with prefixes (stg_, int_, dim_, fct_)
- Columns: snake_case, descriptive names
- Tables: Singular nouns (user, not users)
- Primary Keys: Always end with '_id' (user_id, order_id)
Folder Structure and Materializations
- staging/: Views only, basic transformations
- intermediate/: Views, complex business logic
- marts/: Tables or incremental, final business models
- All models tagged by domain and layer
Documentation Requirements
- All models require descriptions
- Business-critical columns need descriptions
- Primary keys need unique and not_null tests
- Foreign keys need relationships tests
Business Logic Patterns
- Always use UTC for timestamps
- Standardize null handling with COALESCE
- Use consistent date formatting (YYYY-MM-DD)
- Apply consistent rounding rules (2 decimal places for currency)
Quality Standards
- All models must compile without warnings
- Use consistent test patterns across similar model types
- Maintain referential integrity through proper testing