Looking for some of the best practices we follow when building in LookML? Here are some helpful tips:
total_[FIELD]
for sum, count_[FIELD]
, avg_[FIELD]
, etc.date
or time
in a dimension group because Looker appends each timeframe to the end of the dimension name: created_date
becomes created_date_date
,created_date_month
, etc. Simply use created
which becomes created_date
, created_month
, etc.include:
statements, remove Views from models if unnecessary or use the wildcard. For example include: “user*.view.lookml”
or include: “user*.view”
[New LookML] if several user Views (named user_order_facts, users, user_address…) are needed in the model.model
parameters from dashboard elements). More on these here and here.fields:
parameter for each join or at the Explore level to limit the number of dimensions, measures and filters in the field picker.description:
parameter.fields:
parameter to limit this if possible. This also warrants using several View extensions to repeat core fields and add more unique fields for specific Explores.###Join Design###
sql_on
over foreign_key
for better readability and LookML flexibility.${}
unless referring to a date. For date joins use raw sql (or timeframe raw
on Looker 3.32+) to avoid cast/convert_tz in join predicates. However, avoid joining on concatenated primary keys declared in Looker - Join on the base fields from the table for faster queries. More on referencing fields here.relationship:
parameter to ensure correct aggregates are produced.primary_key
in every View on the field that defines unique rows to ensure accuracy. More on why here.hidden:
parameter on dimensions that will never be used to avoid confusion (such as join Keys/IDs and compound primary keys, or those designed solely for application use.)description: ‘my great description’
). Typical database column names are not descriptive enough for end users.count distinct
of the foreign key from the Explore, to avoid unnecessary joins (i.e. user_count = count(distinct orders.user_id)view_label
and group_label
parameters to consolidate dimensions and measures from multiple joined Views that fall under the same category.sql_trigger_value
over persist_for
when data should be ready the first time someone runs an explore or on a schedule. More on why here.sql_trigger_value
schedules such that tables are not building during business hours/replication processes/peak usage times. Trigger the tables late in the night or early in the morning, after ETL is expected to be completed.