Best Practices: Was Sie mit LookML tun und was nicht

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.

        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 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:
  • 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 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.