Best practice: cosa fare e cosa non fare con LookML

Queste best practice riflettono i consigli condivisi da un team interfunzionale di esperti Looker. Questi approfondimenti provengono da anni di esperienza di collaborazione con i clienti di Looker, dall'implementazione al successo a lungo termine. Le best practice sono scritte per essere utilizzate dalla maggior parte degli utenti e in diverse situazioni, ma, come sempre, usa il tuo miglior giudizio quando implementi i consigli condivisi in questa pagina.

Eseguire questa operazione con LookML

• Azione: definisci il parametro relationship per tutte le unioni.
  In questo modo, le metriche verranno aggregate correttamente in Looker. Per impostazione predefinita, Looker utilizzerà una relazione di join many_to_one per tutte le unioni in cui non è definita una relazione. Per ulteriori informazioni sulla definizione corretta del parametro relationship, consulta la pagina Best practice su come impostare correttamente il parametro relationship.
• Azione: definisci una chiave primaria in ogni visualizzazione, incluse le tabelle derivate.
  Tutte le visualizzazioni, siano esse derivate o provenienti direttamente dal database, devono contenere una chiave primaria. Questa chiave primaria deve essere un valore univoco per consentire a Looker di identificare in modo univoco qualsiasi record. Questa chiave primaria può essere una singola colonna o una concatenazione di colonne: deve semplicemente essere un identificatore univoco per la tabella o la tabella derivata.
• Da fare: assegna nomi alle dimensioni, alle misure e ad altri oggetti LookML utilizzando solo lettere minuscole e trattini bassi per gli spazi.
  Il parametro label può essere utilizzato per la formattazione aggiuntiva di un campo del nome e anche per personalizzare l'aspetto dei nomi delle visualizzazioni, dei nomi delle esplorazioni e dei nomi dei modelli. Ad esempio, nel seguente codice LookML, il parametro label viene utilizzato per assegnare l'etichetta Numero di clienti alla misura customer_count_distinct.

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

• Azione: utilizza i gruppi di dati per allineare la generazione di tabelle derivate permanenti (PDT) e la memorizzazione nella cache delle esplorazioni con i processi ETL sottostanti. I gruppi di dati possono essere utilizzati anche per attivare l'invio di dashboard o Look per garantire che i dati aggiornati vengano inviati ai destinatari.

Non eseguire questa operazione con LookML

• Non: utilizza il parametro from per rinominare le visualizzazioni all'interno di un'esplorazione.
  Utilizza invece il parametro view_label. Per saperne di più sulla differenza tra from e view_label, consulta la pagina della documentazione del parametro from (per le esplorazioni). Il parametro from deve essere utilizzato principalmente nelle seguenti situazioni:
  • Join polimorfici (unione della stessa tabella più volte)
  • Self-join (unione di una tabella con se stessa)
  • Reimpostazione dell'ambito di una visualizzazione estesa al nome della visualizzazione originale
• Non: utilizzare la parola "data" o "ora" nel nome di un gruppo di dimensioni.
  Looker aggiunge ogni periodo di tempo alla fine del nome del gruppo di dimensioni, il che significa che un gruppo di dimensioni denominato created_date genera campi denominati, ad esempio, created_date_date e created_date_month. Utilizza semplicemente created come nome del gruppo di dimensioni, in quanto i campi verranno denominati, ad esempio, created_date e created_month.
• Non: utilizza i timestamp formattati all'interno delle unioni.
  Utilizza invece l'opzione periodo di tempo non elaborato per l'unione in base a qualsiasi campo di data o ora. In questo modo, eviterai l'inclusione di conversioni di tipo di dati e fuso orario nei predicati di join.