[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-31。"],[],[],null,["# Best practice: What to do and what not to do with LookML\n\nThese 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.\n\nDo this with LookML\n-------------------\n\n- **Do** : Define the [`relationship`](/looker/docs/reference/param-explore-join-relationship) parameter for all joins.\n\n \u003cbr /\u003e\n\n This will ensure that metrics aggregate properly within Looker. By default, Looker will use a `many_to_one` join relationship for any joins in which a relationship is not defined. For additional information on defining the `relationship` parameter correctly, see the Best Practices page on [getting the `relationship` parameter right](/looker/docs/best-practices/how-to-use-the-relationship-parameter-correctly).\n- **Do** : Define a [primary key](/looker/docs/reference/param-field-primary-key) within each and every view, including derived tables.\n\n \u003cbr /\u003e\n\n 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.\n- **Do** : Name [dimensions](/looker/docs/reference/param-field-dimension), [measures](/looker/docs/reference/param-field-measure), and other LookML objects, using all lowercase letters and underscores for spaces.\n\n \u003cbr /\u003e\n\n The [`label` parameter](/looker/docs/reference/param-field-label) can be used for additional formatting of a name field, and can also be used to customize the appearance of [view names](/looker/docs/reference/param-view-label), [Explore names](/looker/docs/reference/param-explore-label), and [model names](/looker/docs/reference/param-model-label). For example, in the following LookML, the `label` parameter is used to assign the label **Number of Customers** to the `customer_count_distinct` measure. \n\n ```\n measure: customer_count_distinct {\n label: \"Number of Customers\"\n type: count_distinct\n sql: ${customer.id} ;;\n }\n ```\n- **Do** : Use [datagroups](/looker/docs/reference/param-model-datagroup) to align generation of [persistent derived tables (PDTs)](/looker/docs/caching-and-datagroups) and Explore caching with underlying ETL processes. Datagroups can also be used to trigger deliveries of [dashboards](/looker/docs/scheduling-and-sending-dashboards#schedules_triggered_by_datagroup_updates) or [Looks](/looker/docs/delivering-looks-explores#specifying_the_datagroup_trigger) to ensure that up-to-date data is sent to recipients.\n\nDon't do this with LookML\n-------------------------\n\n- **Don't** : Use the `from` parameter for renaming views within an Explore.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n Use the [`view_label`](/looker/docs/reference/param-explore-view-label) parameter instead. For more on the difference between `from` and `view_label`, check out the [`from` (for Explores)](/looker/docs/reference/param-explore-from) parameter documentation page. The `from` parameter should primarily be used in the following situations:\n - Polymorphic joins (joining the same table multiple times)\n - [Self-joins](/looker/docs/working-with-joins#joining_a_view_more_than_once) (joining a table to itself)\n - Re-scoping an extended view back to its original view name\n- **Don't** : Use the word \"date\" or \"time\" in a [dimension group](/looker/docs/reference/param-field-dimension-group) name.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n 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` and `created_date_month`. Simply use `created` as the dimension group name, because this results in fields that are named, for example, `created_date` and `created_month`.\n- **Don't** : Use formatted timestamps within joins.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n Instead, use the [raw timeframe](/looker/docs/reference/param-field-dimension-group#timeframes) option for joining on any date or time fields. This will avoid the inclusion of casting and timezone conversion in join predicates."]]