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 le viste anziché con le 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 di 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 Panoramica delle viste. 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 viste per creare grafici

Quando utilizzi le viste per creare elementi del grafico, devi rispettare i seguenti requisiti:

Utilizza la clausola KEY quando specifichi un elemento del grafico

Quando utilizzi le viste per creare un elemento nodo o bordo, devi definire esplicitamente le colonne che identificano in modo univoco l'elemento del grafico. Per farlo, utilizza la clausola KEY nella definizione dell'elemento nodo o bordo. Per scoprire come utilizzare la KEY clausola durante la creazione di un elemento del grafo, consulta gli esempi di codice in questo documento e in Creare uno Spanner Graph da una vista SQL.

Assicurati che le chiavi di nodi e bordi siano univoche

Ogni nodo e bordo in un grafico delle proprietà deve avere una chiave univoca. Quando definisci gli elementi del grafico utilizzando le viste, puoi scegliere come verificare l'univocità della chiave dell'elemento:

Convalida rigorosa delle chiavi (impostazione predefinita)

Per impostazione predefinita, Spanner verifica che le viste che definiscono le tabelle di nodi o bordi seguano uno dei seguenti pattern per garantire che ogni nodo o bordo sia univoco:

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

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

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 univocità 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 nodi o bordi prodotta dalla vista è univoca.

Ad esempio, la seguente query seleziona un sottoinsieme di righe dalla tabella Account. La chiave del grafico KEY(account_id) corrisponde alla chiave primaria della tabella Account, il che garantisce che ogni riga prodotta dalla vista 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)
  );

Pattern 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 alle colonne utilizzate da queste clausole per definire l'univocità:

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

  • Per SELECT DISTINCT: le colonne della clausola KEY devono corrispondere alle colonne nell'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)
  );

Convalida delle chiavi disattivata (qualsiasi query SQL)

Se la tua vista utilizza una query che non segue il pattern 1 o il pattern 2, ad esempio una query che unisce le tabelle senza una clausola GROUP BY o SELECT DISTINCT, puoi disattivare la convalida della chiave dell'elemento impostando l'opzione del grafico validate_element_key_uniqueness = false.

Per impostazione predefinita, validate_element_key_uniqueness è true. Se impostato su false, Spanner non convalida la definizione della query della vista al momento della creazione dello schema. Puoi utilizzare qualsiasi query SQL nella vista, ma devi assicurarti che le colonne specificate nella clausola KEY contengano valori univoci per ogni riga di nodi o bordi.

L'esempio seguente definisce una vista denominata CustomerOrderTrusted che unisce le Customer e SaleOrder tabelle senza una GROUP BY clausola. Poiché ogni ordine di vendita è univoco, l'unione di SaleOrder con Customer mantiene l'univocità di order_id nei risultati della vista. Tuttavia, poiché la query utilizza un'operazione JOIN e non segue il pattern 1 o il pattern 2, Spanner non può verificare l'univocità sintatticamente.

Specificando KEY(order_id) e impostando validate_element_key_uniqueness = false nella clausola OPTIONS, puoi definire il grafico delle proprietà senza modificare la query della vista:

-- View uses a JOIN without GROUP BY or DISTINCT.
CREATE VIEW CustomerOrderTrusted
  SQL SECURITY INVOKER AS
    SELECT
      s.order_id,
      c.customer_id,
      c.name AS customer_name
    FROM Customer c JOIN SaleOrder s ON c.customer_id = s.customer_id;

-- Property graph disables element key uniqueness validation.
CREATE PROPERTY GRAPH OrderGraphTrusted
  NODE TABLES (
    CustomerOrderTrusted
      KEY(order_id)
      LABEL CustomerOrder PROPERTIES(
        order_id,
        customer_id,
        customer_name)
  ) OPTIONS (validate_element_key_uniqueness = false);

Considerazioni sull'utilizzo delle viste

Quando utilizzi le viste per definire gli elementi del grafico, le seguenti operazioni possono aiutarti a progettare e implementare un grafico efficace:

Rendimento delle query del grafico delle proprietà

Quando definisci gli elementi del grafico sulle viste che eseguono trasformazioni dei dati (ad esempio, operazioni GROUP BY, UNNEST o JOIN), valuta attentamente il rendimento 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 dei 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, tutte le ottimizzazioni della tabella sottostante rimangono efficaci per le query del grafico. Ad esempio, l'applicazione delle seguenti tecniche alle tabelle di base offre vantaggi in termini di rendimento simili per gli elementi del grafico definiti su queste viste:

Viste definite con la clausola GROUP BY o DISTINCT

Le viste 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 delle tabelle di base potrebbero non fornire gli stessi vantaggi in termini di rendimento per le query del grafico che operano sulle viste. Valuta attentamente il rendimento delle query per il tuo caso d'uso quando le viste eseguono aggregazioni complesse.

Modifica dei dati con grafici basati su viste

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

Gestione degli errori del grafico per applicare 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 l'errore delle query sul grafico basato su viste in fase di runtime.

Ad esempio, quando esegui la transizione da un grafico 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 e prevenire 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