Bonnes pratiques: choses à faire et à ne pas faire avec LookML

Ces bonnes pratiques reflètent les recommandations partagées par une équipe interfonctionnelle de Lookers expérimentés. Ces insights sont issus de nos années d'expérience auprès des clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour s'adapter à la plupart des utilisateurs et des situations. Toutefois, comme toujours, faites appel à votre bon sens lorsque vous appliquez les recommandations fournies sur cette page.

Règles LookML

• À faire : définissez le paramètre relationship pour toutes les jointures.
  Vous vous assurerez ainsi que les métriques sont correctement agrégées dans Looker. Par défaut, Looker utilise une relation de jointure many_to_one pour toutes les jointures pour lesquelles aucune relation n'est définie. Pour en savoir plus sur la définition correcte du paramètre relationship, consultez la page des bonnes pratiques pour bien définir le paramètre relationship.
• À faire: définissez une clé primaire dans chaque vue, y compris les tables dérivées.
  Toutes les vues, qu'elles soient dérivées ou issues directement de la base de données, doivent contenir une clé primaire. Cette clé primaire doit être une valeur unique permettant à Looker d'identifier de façon unique un enregistrement donné. Cette clé primaire peut être une colonne unique ou une concaténation de colonnes. Il s'agit simplement d'un identifiant unique pour la table ou la table dérivée.
• À faire: nommez les dimensions, les mesures et les autres objets LookML en utilisant des lettres minuscules et des traits de soulignement pour les espaces.
  Le paramètre label permet de mettre en forme un champ de nom de manière supplémentaire. Il peut également être utilisé pour personnaliser l'apparence des noms de vues, des noms d'explorations et des noms de modèles. Par exemple, dans le code LookML suivant, le paramètre label est utilisé pour attribuer le libellé Nombre de clients à la mesure customer_count_distinct.

        measure: customer_count_distinct {
          label: "Number of Customers"
          type: count_distinct
          sql: ${customer.id} ;;
        }

• À faire : utilisez des groupes de données pour aligner la génération de tables dérivées persistantes (PDT) et explorez la mise en cache avec les processus ETL sous-jacents. Les groupes de données peuvent également être utilisés pour déclencher l'envoi de tableaux de bord ou de présentations afin de vous assurer que des données à jour sont envoyées aux destinataires.

À éviter avec LookML

• Ne pas : utiliser le paramètre from pour renommer des vues dans une exploration.
  Utilisez plutôt le paramètre view_label. Pour en savoir plus sur la différence entre from et view_label, consultez la page de documentation du paramètre from (pour les explorations). Le paramètre from doit principalement être utilisé dans les situations suivantes:
  • Jointures polymorphes (jointure de la même table plusieurs fois)
  • Autojointures (joindre une table à elle-même)
  • Rétablir le nom d'origine d'une vue étendue
• À éviter: n'utilisez pas le mot "date". ou "heure" dans un nom de groupe de dimensions.
  Looker ajoute chaque période à la fin du nom du groupe de dimensions. Cela signifie qu'un groupe de dimensions nommé created_date génère des champs nommés created_date_date, created_date_month, etc. Utilisez simplement created comme nom de groupe de dimensions, car les champs seront nommés created_date, created_month, etc.
• Ne pas : utiliser des codes temporels formatés dans les jointures.
  Utilisez plutôt l'option Période brute pour effectuer une jointure sur des champs de date ou d'heure. Cela permet d'éviter l'inclusion de la conversion de fuseau horaire et de la conversion de fuseau horaire dans les prédicats de jointure.