These best practices reflect recommendations that were shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but — as always — use your best judgment when implementing any of the recommendations that are shared on this page.
Do this with LookML
-
Do: Define the
relationship
parameter for all joins. This will ensure that metrics aggregate properly within Looker. By default, Looker will use amany_to_one
join relationship for any joins in which a relationship is not defined. For additional information on defining therelationship
parameter correctly, see the Best Practices page on getting therelationship
parameter right. - Do: Define a primary key within each and every view, including derived tables. All views, whether they are derived or coming directly from the database, should contain a primary key. This primary key should be a unique value to enable Looker to uniquely identify any given record. This primary key can be a single column or a concatenation of columns — it simply needs to be a unique identifier for the table or derived table.
-
Do: Name dimensions, measures, and other LookML objects, using all lowercase letters and underscores for spaces.
The
label
parameter can be used for additional formatting of a name field, and can also be used to customize the appearance of view names, Explore names, and model names. For example, in the following LookML, thelabel
parameter is used to assign the label Number of Customers to thecustomer_count_distinct
measure.measure: customer_count_distinct { label: "Number of Customers" type: count_distinct sql: ${customer.id} ;; }
- Do: Use datagroups to align generation of persistent derived tables (PDTs) and Explore caching with underlying ETL processes. Datagroups can also be used to trigger deliveries of dashboards or Looks to ensure that up-to-date data is sent to recipients.
Don't do this with LookML
-
Don't: Use the
from
parameter for renaming views within an Explore. Use theview_label
parameter instead. For more on the difference betweenfrom
andview_label
, check out thefrom
(for Explores) parameter documentation page. Thefrom
parameter should primarily be used in the following situations:- Polymorphic joins (joining the same table multiple times)
- Self-joins (joining a table to itself)
- Re-scoping an extended view back to its original view name
-
Don't: Use the word "date" or "time" in a dimension group name.
Looker appends each timeframe to the end of the dimension group name, which means that a dimension group that is named
created_date
results in fields called, for example,created_date_date
andcreated_date_month
. Simply usecreated
as the dimension group name, because this results in fields that are named, for example,created_date
andcreated_month
. - Don't: Use formatted timestamps within joins. Instead, use the raw timeframe option for joining on any date or time fields. This will avoid the inclusion of casting and timezone conversion in join predicates.