Panoramica dei grafici creati dalle viste SQL

Utilizza questo documento per scoprire i vantaggi dell'utilizzo delle viste SQL per creare un grafico. Questo documento include i vantaggi della creazione di grafici con le viste, i requisiti e le considerazioni per aiutarti a decidere se utilizzare tabelle o viste per creare un grafico.

Per informazioni dettagliate su come creare un grafico dalle viste, consulta Creare un grafico delle proprietà dalle viste SQL.

Vantaggi della creazione di grafici con visualizzazioni anziché tabelle

Una vista SQL è una tabella virtuale definita da una query SQL. In Spanner, la query che definisce una vista viene eseguita ogni volta che viene eseguita una query che fa riferimento alla vista. Le viste Spanner non sono viste materializzate perché non archiviano i risultati della query che definisce la vista come tabella effettiva nell'archiviazione dei dati. Per saperne di più, consulta la panoramica delle visualizzazioni. Puoi creare elementi del grafico dalle viste SQL, ma non puoi creare una vista che esegue query su un grafico.

Le viste offrono diversi vantaggi come livello di astrazione tra le tabelle e uno schema del grafico che non sono disponibili quando utilizzi le tabelle per creare un grafico.

Requisiti per l'utilizzo delle visualizzazioni per creare grafici

Devi rispettare questi requisiti quando utilizzi le visualizzazioni per creare elementi del grafico:

Utilizza la clausola KEY quando specifichi un elemento del grafico

Quando utilizzi le visualizzazioni per creare un nodo o un elemento edge, devi definire in modo esplicito le colonne che identificano in modo univoco l'elemento del grafico. A tale scopo, utilizza la clausola KEY nella definizione dell'elemento nodo o arco. Per scoprire come utilizzare la clausola KEY durante la creazione di un elemento del grafico, consulta gli esempi di codice in questo documento e in Creare un grafico Spanner da una vista SQL.

Utilizza visualizzazioni che garantiscano l'unicità di nodi e archi

Le viste che definiscono tabelle di nodi o archi devono seguire uno dei seguenti pattern per garantire che i nodi e gli archi siano univoci:

  • Pattern 1: la visualizzazione utilizza la chiave primaria di una singola tabella.

  • Pattern 2: la vista utilizza una clausola GROUP BY o SELECT DISTINCT.

Puoi utilizzare altri operatori SQL come WHERE, HAVING, ORDER BY,LIMIT e TABLESAMPLE in combinazione con questi pattern. Questi operatori filtrano o ordinano i risultati, ma non modificano la garanzia di unicità sottostante fornita dai pattern.

Pattern 1: utilizza la chiave primaria di una singola tabella

In questo pattern, la vista seleziona da una singola tabella e la clausola KEY nella definizione del grafico corrisponde alle colonne della chiave primaria della tabella di base. Per questo motivo, ogni riga di nodo o arco prodotta dalla visualizzazione è unica.

Ad esempio, la seguente query seleziona un sottoinsieme di righe dalla tabella Account. Il grafico KEY(account_id) corrisponde alla chiave primaria della tabella Account, il che garantisce che ogni riga prodotta dalla visualizzazione sia univoca.

-- Table has PRIMARY KEY(account_id).
CREATE TABLE Account (
  account_id INT64 NOT NULL,
  customer_id INT64 NOT NULL,
  account_type STRING(MAX),
  balance INT64
) PRIMARY KEY(account_id);

-- Pattern 1: View uses the primary key from a single table.
CREATE VIEW SavingAccount
  SQL SECURITY INVOKER AS
    SELECT accnt.account_id, accnt.customer_id, accnt.balance
    FROM Account accnt
    WHERE accnt.account_type = 'saving';

CREATE PROPERTY GRAPH SavingAccountGraph
  NODE TABLES (
    -- The element KEY(account_id) matches the table's primary key.
    SavingAccount KEY(account_id)
  );

Modello 2: utilizza la clausola GROUP BY o SELECT DISTINCT

In questo pattern, la query della vista utilizza una clausola GROUP BY o SELECT DISTINCT. Le colonne nella clausola KEY devono corrispondere a quelle che queste clausole utilizzano per definire l'univocità:

  • Per GROUP BY: le colonne della clausola KEY devono corrispondere a tutte le colonne della clausola GROUP BY.

  • Per SELECT DISTINCT: le colonne della clausola KEY devono corrispondere alle colonne dell'elenco SELECT DISTINCT.

Esempio con GROUP BY:

CREATE TABLE Customer (
  customer_id INT64,
  name STRING(MAX)
) PRIMARY KEY (customer_id);

CREATE TABLE SaleOrder (
  order_id INT64,
  customer_id INT64,
  amount INT64
) PRIMARY KEY (order_id);

CREATE VIEW CustomerOrder
  SQL SECURITY INVOKER AS
    SELECT
      s.order_id,
      ANY_VALUE(c.customer_id) AS customer_id,
      ANY_VALUE(c.name) AS customer_name
    FROM Customer c JOIN SaleOrder s ON c.customer_id = s.customer_id
    GROUP BY s.order_id;

CREATE PROPERTY GRAPH OrderGraph
  NODE TABLES (
    -- The KEY(order_id) matches the GROUP BY column in view definition.
    CustomerOrder KEY(order_id)
  );

Esempio con SELECT DISTINCT:

CREATE TABLE SaleOrder (
  order_id INT64,
  customer_id INT64,
  amount INT64
) PRIMARY KEY (order_id);

CREATE VIEW KeyCustomer SQL SECURITY INVOKER AS
  SELECT DISTINCT s.customer_id, s.amount
  FROM SaleOrder s
  WHERE s.amount > 1000;

CREATE PROPERTY GRAPH KeyCustomersGraph
  NODE TABLES (
    -- The KEY(customer_id, amount) matches the DISTINCT columns.
    KeyCustomer KEY(customer_id, amount)
  );

Considerazioni sull'utilizzo delle visualizzazioni

Quando utilizzi le visualizzazioni per definire gli elementi del grafico, quanto segue può aiutarti a progettare e implementare un grafico efficace:

Prestazioni delle query del grafico delle proprietà

Quando definisci gli elementi del grafico nelle visualizzazioni che eseguono trasformazioni dei dati (ad esempio, operazioni GROUP BY, UNNEST o JOIN), valuta attentamente le prestazioni delle query per il tuo caso d'uso. Ricorda che Spanner esegue la definizione della query di una vista ogni volta che una query esegue la corrispondenza del pattern degli elementi.

Ottimizzazione dello schema del grafico

Quando utilizzi le viste per definire gli elementi del grafico, alcune ottimizzazioni dello schema del grafico potrebbero essere meno efficaci rispetto a quando utilizzi le tabelle per definire gli elementi del grafico.

Viste che proiettano la chiave primaria di una singola tabella

Se una vista è una proiezione da una singola tabella di base, qualsiasi ottimizzazione di questa tabella sottostante rimane efficace per le query del grafico. Ad esempio, l'applicazione delle seguenti tecniche alle tabelle di base offre vantaggi simili in termini di rendimento per gli elementi del grafico definiti in queste visualizzazioni:

Viste definite con la clausola GROUP BY o DISTINCT

Le visualizzazioni che eseguono aggregazioni, come GROUP BY, SELECT DISTINCT o altre trasformazioni complesse, perdono la relazione diretta con la struttura della tabella sottostante. Per questo motivo, le ottimizzazioni dello schema nelle tabelle di base potrebbero non offrire gli stessi vantaggi in termini di prestazioni per le query del grafico che operano sulle viste. Valuta attentamente il rendimento delle query per il tuo caso d'uso quando le tue visualizzazioni eseguono aggregazioni complesse.

Modifica dei dati con grafici basati sulla visualizzazione

Le viste non sono materializzate, il che significa che non memorizzano i risultati della query che definisce la vista come tabella nell'archivio dati e sono di sola lettura. Per questo motivo, per inserire, aggiornare o eliminare nodi o archi in un grafico creato dalle viste, devi modificare i dati nelle tabelle utilizzate per creare le viste.

Gestione degli errori del grafico per garantire l'integrità dei dati

Quando utilizzi le viste per definire gli elementi del grafico, applica l'integrità dei dati (ad esempio, applica i tipi di dati) alle tabelle di base sottostanti. In caso contrario, i dati nelle tabelle di base potrebbero non essere validi e causare errori di esecuzione delle query sul grafico basato sulla visualizzazione.

Ad esempio, quando passi da uno schema senza schema a un grafico formalizzato, utilizza i vincoli CHECK per convalidare i dati nelle tabelle di base (GraphNode e GraphEdge). Il seguente codice applica questi vincoli all'interno delle proprietà JSON per garantire l'integrità dei dati all'origine ed evitare errori di query in fase di runtime.

-- Enforce that the 'name' property exists for nodes with the 'person' label.
ALTER TABLE GraphNode
ADD CONSTRAINT NameMustExistForPersonConstraint
CHECK (IF(label = 'person', properties.name IS NOT NULL, TRUE));

-- Enforce that the 'name' property is a string for nodes with the 'person' label.
ALTER TABLE GraphNode
ADD CONSTRAINT PersonNameMustBeStringTypeConstraint
CHECK (IF(label = 'person', JSON_TYPE(properties.name) = 'string', TRUE));

Passaggi successivi