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.Can the link mentioned in the first bullet point of “View Design” be refreshed? I am receiving an error: https://discourse.looker.com/t/making-views-user-friendly/1328
Hi @eFein, This is really good. I was looking for something like this to setup some best practices in my looker project. You saved my time of doing research and documenting this. I think we should keep on updating list here for best practices.
The only thing that I am adamant to do differently is not to call metrics with avg_
as a prefix. I prefer to add it at the end to keep the field alphabetically together like:
net_revenue
net_revenue_avg
net_revenue_median
Otherwise, with more than 10-20 metrics, you have to try to find all possible measures types for one measure
Krishna, do you think it’d be useful to have people add best practices in replies in this topic, or would some kind of Wiki post be better?
Hi @izzymiller, Wiki post is even more better.