Prática recomendada: o que fazer e o que não fazer com o LookML
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Essas práticas recomendadas refletem recomendações compartilhadas por uma equipe multidisciplinar de profissionais experientes do Looker. Esses insights vêm de anos de experiência trabalhando com clientes do Looker, desde a implementação até o sucesso a longo prazo. As práticas foram criadas para funcionar para a maioria dos usuários e situações, mas, como sempre, use seu melhor julgamento ao implementar qualquer uma das recomendações compartilhadas nesta página.
Fazer isso com o LookML
O que fazer: defina o parâmetro relationship para todas as mesclagens.
Isso garante que as métricas sejam agregadas corretamente no Looker. Por padrão, o Looker usa uma relação de mesclagem many_to_one para todas as mesclagens em que uma relação não está definida. Para mais informações sobre como definir o parâmetro relationship corretamente, consulte a página de práticas recomendadas sobre como definir o parâmetro relationship corretamente.
O que fazer: defina uma chave primária em todas as visualizações, incluindo tabelas derivadas.
Todas as visualizações, sejam derivadas ou provenientes diretamente do banco de dados, precisam conter uma chave primária. Essa chave primária precisa ser um valor exclusivo para que o Looker identifique de forma única qualquer registro. Essa chave primária pode ser uma única coluna ou uma concatenação de colunas. Ela simplesmente precisa ser um identificador exclusivo para a tabela ou tabela derivada.
O que fazer: nomeie dimensões, medidas e outros objetos do LookML usando letras minúsculas e sublinhados em vez de espaços.
O parâmetro label pode ser usado para formatar um campo de nome e personalizar a aparência de nomes de visualização, nomes de Explorar e nomes de modelos. Por exemplo, no LookML a seguir, o parâmetro label é usado para atribuir o rótulo Número de clientes à medida customer_count_distinct.
O que fazer: use datagroups para alinhar a geração de tabelas derivadas persistentes (PDTs, na sigla em inglês) e a análise de armazenamento em cache com os processos de ETL subjacentes. Os grupos de dados também podem ser usados para acionar as entregas de painéis ou Looks e garantir que os destinatários recebam dados atualizados.
Não faça isso com o LookML
O que não fazer: use o parâmetro from para renomear visualizações em uma Análise detalhada.
Use o parâmetro view_label. Para saber mais sobre a diferença entre from e view_label, consulte a página de documentação do parâmetro from (para análises detalhadas). O parâmetro from deve ser usado principalmente nas seguintes situações:
Junções polimórficas (mesclagem da mesma tabela várias vezes)
Redefinir o escopo de uma visualização estendida para o nome original
Não use: use a palavra "data" ou "hora" no nome de um grupo de dimensões.
O Looker anexa cada período ao final do nome do grupo de dimensão, o que significa que um grupo de dimensão chamado created_date resulta em campos chamados, por exemplo, created_date_date e created_date_month. Basta usar created como o nome do grupo de dimensões, porque isso resulta em campos com nomes como created_date e created_month.
Não: use carimbos de data/hora formatados nas mesclagens.
Em vez disso, use a opção período bruto para mesclar em qualquer campo de data ou hora. Isso evita a inclusão de casting e conversão de fuso horário em predicados de mesclagem.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-31 UTC."],[],[],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."]]