Gitlab hero border pattern left svg Gitlab hero border pattern right svg

SQL Style Guide


SQL Style Guide

Since we don't have a linter, it is our collective responsibility to enforce this Style Guide.

General Guidelines

Field Naming Conventions

Dates

Use CTEs (Common Table Expressions), not subqueries
General
Functions
JOINs
Example Code
Commenting

dbt Guidelines

General
Sources
Base Models
Organizing columns

When writing a base model, colummns should have some logical ordering to them. We encourage these 4 basic groupings:

Primary data is the key information describing the table. The primary key should be in this group along with other relevant unique attributes such as name.

Foreign keys should be all the columns which point to another table.

Logical data is for additional data dimensions that describe the object in reference. For a Salesforce opportunity this would be the opportunity owner or contract value. Further logical groupings are encouraged if they make sense. For example, having a group of all the variations of contract value would make sense.

Within any group, the columns should be alphabetized on the alias name.

An exception to the grouping recommendation is when we control the extraction via a defined manifest file. A perfect example of this is our gitlab.com manifest which defines which columns we extract from our application database. The base models for these tables can be ordered identically to the manifest as it's easier to compare diffs and ensure accuracy between files.

Testing

Other SQL Style Guides