Best Practices: Was Sie mit LookML tun und was nicht
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Diese Best Practices spiegeln Empfehlungen wider, die von einem funktionsübergreifenden Team erfahrener Looker geteilt wurden. Diese Erkenntnisse basieren auf jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden – von der Implementierung bis hin zum langfristigen Erfolg. Die Best Practices sind so konzipiert, dass sie für die meisten Nutzer und Situationen geeignet sind. Wie immer sollten Sie jedoch bei der Umsetzung der Empfehlungen auf dieser Seite Ihr eigenes Urteilsvermögen einsetzen.
Mit LookML
Empfohlen: Definieren Sie den Parameter relationship für alle Zusammenführungen.
So werden die Messwerte in Looker korrekt zusammengefasst. Standardmäßig verwendet Looker für alle Joins, für die keine Beziehung definiert ist, eine many_to_one-Join-Beziehung. Weitere Informationen zur korrekten Definition des relationship-Parameters finden Sie auf der Seite mit Best Practices zum richtigen Festlegen des relationship-Parameters.
Empfohlen: Definieren Sie in jeder Ansicht einen Primärschlüssel, einschließlich abgeleiteter Tabellen.
Alle Ansichten, unabhängig davon, ob sie abgeleitet oder direkt aus der Datenbank stammen, sollten einen Primärschlüssel enthalten. Dieser Primärschlüssel sollte ein eindeutiger Wert sein, damit Looker jeden Datensatz eindeutig identifizieren kann. Dieser Primärschlüssel kann eine einzelne Spalte oder eine Konkatenierung von Spalten sein. Er muss lediglich eine eindeutige Kennung für die Tabelle oder die abgeleitete Tabelle sein.
Empfohlen: Verwenden Sie für Dimensionen, Messwerte und andere LookML-Objekte ausschließlich Kleinbuchstaben und Unterstriche für Leerzeichen.
Der Parameter label kann für die zusätzliche Formatierung eines Namensfelds verwendet werden. Außerdem können damit die Darstellung von Ansichtsnamen, Explore-Namen und Modellnamen angepasst werden. In der folgenden LookML-Anweisung wird beispielsweise der Parameter label verwendet, um dem Messwert customer_count_distinct das Label Anzahl der Kunden zuzuweisen.
Empfohlen: Verwenden Sie Datengruppen, um die Generierung von persistenten abgeleiteten Tabellen (PDTs) und das Explore-Caching mit den zugrunde liegenden ETL-Prozessen abzugleichen. Mit Datengruppen können Sie auch die Übermittlung von Dashboards oder Looks auslösen, damit Empfänger immer aktuelle Daten erhalten.
Das ist mit LookML nicht möglich
Nicht: Verwenden Sie den Parameter from nicht zum Umbenennen von Ansichten in einem Explore.
Verwenden Sie stattdessen den Parameter view_label. Weitere Informationen zum Unterschied zwischen from und view_label finden Sie auf der Seite mit der Parameterdokumentation für from (für Explores). Der Parameter from sollte hauptsächlich in den folgenden Fällen verwendet werden:
Self Joins (Tabellen werden mit sich selbst zusammengeführt)
Eine erweiterte Ansicht auf den ursprünglichen Ansichtsnamen zurücksetzen
Nicht: Verwenden Sie das Wort „Datum“ oder „Uhrzeit“ nicht im Namen einer Dimensionsgruppe.
In Looker wird jeder Zeitrahmen am Ende des Namens der Dimensionsgruppe angehängt. Das bedeutet, dass eine Dimensionsgruppe mit dem Namen created_date zu Feldern mit Namen wie created_date_date und created_date_month führt. Verwenden Sie einfach created als Namen der Dimensionsgruppe, da dies zu Feldern mit Namen wie created_date und created_month führt.
Nicht: Verwenden Sie keine formatierten Zeitstempel in Joins.
Verwenden Sie stattdessen die Option Raw-Zeitraum, um eine Zusammenführung nach Datums- oder Uhrzeitfeldern vorzunehmen. So wird verhindert, dass Casting und Zeitzonenkonvertierung in Join-Prädikate eingeschlossen werden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
