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, einemany_to_one
-Join-Beziehung. Weitere Informationen zur korrekten Definition desrelationship
-Parameters finden Sie auf der Seite mit Best Practices zum richtigen Festlegen desrelationship
-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 Parameterlabel
verwendet, um dem Messwertcustomer_count_distinct
das Label Anzahl der Kunden zuzuweisen.measure: customer_count_distinct { label: "Number of Customers" type: count_distinct sql: ${customer.id} ;; }
- 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 Parameterview_label
. Weitere Informationen zum Unterschied zwischenfrom
undview_label
finden Sie auf der Seite mit der Parameterdokumentation fürfrom
(für Explores). Der Parameterfrom
sollte hauptsächlich in den folgenden Fällen verwendet werden:- Polymorphe Joins (mehrfache Zusammenführung derselben Tabelle)
- 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 wiecreated_date_date
undcreated_date_month
führt. Verwenden Sie einfachcreated
als Namen der Dimensionsgruppe, da dies zu Feldern mit Namen wiecreated_date
undcreated_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.