Bonne pratique : LookML : bonnes pratiques et pratiques à éviter

Ces bonnes pratiques reflètent les recommandations partagées par une équipe pluridisciplinaire de Looker chevronnés. Ces insights sont le fruit d'années d'expérience avec les clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour fonctionner pour la plupart des utilisateurs et des situations, mais, comme toujours, faites appel à votre bon sens lorsque vous mettez en œuvre les recommandations partagées sur cette page.

À faire avec LookML

• À faire: définissez le paramètre relationship pour toutes les jointures.
  Vous vous assurez 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 dans lesquelles aucune relation n'est définie. Pour savoir comment définir correctement le paramètre relationship, consultez la page des bonnes pratiques sur l'utilisation correcte du paramètre relationship.
• À faire: définissez une clé primaire dans chaque vue, y compris dans les tables dérivées.
  Toutes les vues, qu'elles soient dérivées ou provenant directement de la base de données, doivent contenir une clé primaire. Cette clé primaire doit être une valeur unique pour permettre à Looker d'identifier de manière unique tout enregistrement donné. Cette clé primaire peut être une colonne unique ou une concaténation de colonnes. Elle doit simplement correspondre à un identifiant unique de la table ou de la table dérivée.
• À faire: nommez des dimensions, des mesures et d'autres objets LookML en utilisant uniquement des lettres minuscules et des traits de soulignement pour les espaces.
  Le paramètre label peut être utilisé pour mettre en forme un champ de nom et personnaliser l'apparence des noms de vues, noms d'exploration et noms de modèles. Par exemple, dans le code LookML ci-dessous, le paramètre label permet d'attribuer l'étiquette Number of customers (Nombre de clients) à la mesure customer_count_distinct.

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

• Action recommandée: utilisez des groupes de données pour aligner la génération de tables dérivées persistantes (PDT) et la mise en cache d'explorations sur les processus ETL sous-jacents. Les groupes de données peuvent également servir à déclencher l'envoi de tableaux de bord ou de présentations afin de s'assurer que des données à jour sont envoyées aux destinataires.

À ne pas faire avec LookML

• À éviter: utilisez le paramètre from pour renommer les vues d'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 être utilisé principalement dans les situations suivantes :
  • Jointures polymorphes (jointure plusieurs fois à la même table)
  • Autojointures (jointures d'une table à elle-même)
  • Adapter le champ d'application d'une vue étendue à son nom d'origine
• À éviter: n'utilisez pas le mot "date" ou "heure" dans le nom d'un groupe de dimensions.
  Looker ajoute chaque période à la fin du nom du groupe de dimensions. Autrement dit, 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 il en résulte des champs nommés created_date, created_month, etc.
• À éviter: utilisez des horodatages mis en forme dans les jointures.
  Utilisez plutôt l'option de période brute pour joindre tous les champs de date ou d'heure. Vous éviterez ainsi d'inclure la diffusion et la conversion de fuseau horaire dans les prédicats de jointure.