Chaves externas

Este documento descreve as chaves estrangeiras no Spanner e como elas podem ser usadas para impor a integridade referencial no banco de dados. Os tópicos a seguir ajudam você a aprender sobre chaves estrangeiras e como usá-las:

Visão geral das chaves externas no Spanner

As chaves externas definem relações entre tabelas. É possível usar chaves externas para garantir que a integridade de dados desses relacionamentos no Spanner seja mantida.

Imagine que você seja o desenvolvedor principal de uma empresa de e-commerce. Você está projetando um banco de dados para processar pedidos dos clientes. O banco de dados precisa armazenar informações sobre cada pedido, cliente e produto. A figura 1 ilustra a estrutura de banco de dados básica do aplicativo.

Estrutura básica do banco de dados de processamento de pedidos.

Figura 1. Diagrama de um banco de dados de processamento de pedidos

Você define uma tabela Customers para armazenar informações do cliente, uma tabela Orders para acompanhar todos os pedidos e uma tabela Products para armazenar informações sobre cada produto.

A figura 1 também mostra links entre as tabelas que mapeiam aos seguintes relacionamentos reais:

  • Um cliente faz um pedido.

  • Um pedido é feito para um produto.

Você decide que seu banco de dados precisa aplicar as regras a seguir para garantir que os pedidos no sistema sejam válidos.

  • Não é possível criar um pedido para um cliente que não existe.

  • Um cliente não pode fazer um pedido de um produto que você não tem disponível.

Quando você aplica essas regras, ou restrições, está mantendo a integridade referencial dos seus dados. Quando um banco de dados mantém a integridade referencial, todas as tentativas de adicionar dados inválidos, o que resultaria em links ou referências inválidas entre os dados, falham. A integridade referencial evita erros do usuário. Por padrão, o Spanner usa chaves estrangeiras para aplicar a integridade referencial.

Definir integridade referencial com chaves estrangeiras

O exemplo a seguir examina o processamento de pedidos novamente, com mais detalhes adicionados ao projeto, conforme mostrado na Figura 2.

Esquema do banco de dados com chaves estrangeiras

Figura 2. Diagrama de um esquema de banco de dados com chaves estrangeiras

O design agora mostra nomes e tipos de colunas em cada tabela. A tabela Orders também define dois relacionamentos de chave estrangeira. FK_CustomerOrder espera que todas as linhas em Orders tenham um CustomerId válido. A chave externa FK_ProductOrder espera que todos os valores ProductId na tabela Orders sejam válidos. A tabela a seguir mapeia essas restrições de volta às regras reais que você quer aplicar.

Nome da chave estrangeira Restrição Descrição real
FK_CustomerOrder Espera que todas as linhas em Orders tenham um CustomerId válido Um cliente válido faz um pedido
FK_ProductOrder Espera que todas as linhas em Orders tenham um ProductId válido Um produto válido foi solicitado

O Spanner aplica restrições especificadas usando chaves estrangeiras aplicadas. Isso significa que o Spanner falha em qualquer transação que tente inserir ou atualizar uma linha na tabela Orders que tenha um CustomerId ou ProductId não encontrado nas tabelas Customers e Products. Ele também falha em transações que tentam atualizar ou excluir linhas nas tabelas Customers e Products que invalidariam os IDs na tabela Orders. Para mais detalhes sobre como o Spanner valida restrições, consulte a seção Validação de restrição de transação.

Ao contrário das chaves externas aplicadas, o Spanner não valida restrições em chaves externas informativas. Isso significa que, se você usar uma chave externa informativa nesse cenário, uma transação que tente inserir ou atualizar uma linha na tabela Orders que tenha um CustomerId ou ProductId não encontrado nas tabelas Customers e Products não será validada e não vai falhar. Além disso, ao contrário das chaves estrangeiras obrigatórias, as chaves estrangeiras informativas são compatíveis apenas com o GoogleSQL, não com o PostgreSQL.

Características da chave externa

Confira a seguir uma lista de características de chaves externas no Spanner.

  • A tabela que define a chave externa é a tabela de referência, e as colunas de chave externa são as colunas de referência.

  • A chave externa faz referência às colunas referenciadas da tabela referenciada.

  • Como no exemplo, você pode nomear cada restrição chave externa. Se você não especificar um nome, o Spanner vai gerar um para você. É possível consultar o nome gerado no INFORMATION_SCHEMA do Spanner. Os nomes das restrições têm como escopo o esquema, além dos nomes das tabelas e índices, por exemplo. Eles precisam ser exclusivos dentro do esquema.

  • O número de colunas de referência e referenciadas precisa ser o mesmo. A ordem é importante. Por exemplo, a primeira coluna de referência se refere à primeira coluna referenciada, e a segunda coluna de referência se refere à segunda coluna referenciada.

  • As colunas de referência e a contraparte referenciada precisam ser do mesmo tipo. É necessário indexar as colunas.

  • Não é possível criar chaves estrangeiras em colunas com a opção allow_commit_timestamp=true.

  • As colunas da matriz não são compatíveis.

  • Colunas JSON não são compatíveis.

  • Uma chave externa pode fazer referência a colunas da mesma tabela (uma chave externa de autorreferência). Um exemplo é uma tabela Employee com uma coluna ManagerId que faz referência à coluna EmployeeId da tabela.

  • As chaves estrangeiras também podem formar relações circulares entre tabelas, em que duas tabelas fazem referência umas às outras, de maneira direta ou indireta. A tabela referenciada precisa existir antes da criação de uma chave externa. Isso significa que pelo menos uma das chaves estrangeiras precisa ser adicionada usando a instrução ALTER TABLE.

  • As chaves referenciadas precisam ser exclusivas. O Spanner usa o PRIMARY KEY da tabela referenciada se as colunas referenciadas de uma chave externa corresponderem às colunas da chave primária da tabela referenciada. Se o Spanner não puder usar a chave primária da tabela referenciada, ele criará um UNIQUE NULL_FILTERED INDEX nas colunas referenciadas.

  • As chaves estrangeiras não usam índices secundários criados. Em vez disso, elas criam seus próprios índices de backup. Os índices de backup podem ser usados em avaliações de consulta, incluindo em diretivas force_index explícitas. É possível consultar os nomes dos índices de backup no INFORMATION_SCHEMA do Spanner. Para mais informações, consulte Índices de backup.

Tipos de chaves externas

Há dois tipos de chaves externas: aplicadas e informativas. As chaves externas aplicadas são o padrão e garantem a integridade referencial. As chaves estrangeiras informativas não aplicam a integridade referencial e são mais adequadas para declarar o modelo de dados lógicos pretendido para otimização de consultas. Para mais detalhes, consulte as seções a seguir sobre chaves externas obrigatórias e informativas, além da tabela de comparação de tipos de chave externa externas.

Chaves estrangeiras aplicadas

As chaves externas aplicadas, o tipo padrão de chave externa no Spanner, aplicam a integridade referencial. Como as chaves estrangeiras aplicadas aplicam a integridade referencial, elas fazem com que as tentativas de fazer o seguinte falhem:

  • A adição de uma linha a uma tabela de referência que tem um valor chave externa que não existe na tabela referenciada falha.

  • A exclusão de uma linha de uma tabela referenciada por linhas na tabela de referência falha.

Todas as chaves estrangeiras do PostgreSQL são aplicadas. As chaves estrangeiras do GoogleSQL são aplicadas por padrão. Como as chaves estrangeiras são aplicadas por padrão, usar a palavra-chave ENFORCED para especificar que uma chave externa do GoogleSQL é aplicada é opcional.

Chaves externas informativas

As chaves estrangeiras informativas são usadas para declarar o modelo de dados lógico pretendido para otimização de consultas. Embora as chaves de tabela referenciadas precisem ser exclusivas para chaves externas informativas, a integridade referencial não é aplicada. Se você quiser validar seletivamente a integridade referencial ao usar chaves estrangeiras informativas, gerencie a lógica de validação no lado do cliente. Para mais informações, consulte Usar chaves externas informativas.

Use a palavra-chave NOT ENFORCED para especificar que uma chave externa do GoogleSQL é informativa. O PostgreSQL não é compatível com chaves estrangeiras informativas.

Comparação de tipos de chave externa

As opções obrigatória e informativa têm benefícios. As seções a seguir comparam os dois tipos de chaves estrangeiras e incluem algumas práticas recomendadas.

Diferenças de chave externa de alto nível

Em um nível geral, estas são algumas das diferenças entre chaves estrangeiras aplicadas e informativas:

  • Aplicação. As chaves estrangeiras aplicadas validam e garantem a integridade referencial nas gravações. As chaves estrangeiras informativas não validam nem garantem a integridade referencial.

  • Storage. As chaves externas aplicadas podem exigir armazenamento extra para o índice de aplicação na tabela restrita.

  • Capacidade de processamento de gravação. As chaves externas aplicadas podem gerar mais sobrecarga no caminho de gravação do que as chaves externas informativas.

  • Otimização de consultas. Os dois tipos de chaves estrangeiras podem ser usados para otimização de consultas. Quando o otimizador pode usar chaves estrangeiras informativas, os resultados da consulta podem não refletir os dados reais se eles não corresponderem às relações de chave externa informativa (por exemplo, se algumas chaves restritas não tiverem chaves referenciadas correspondentes na tabela referenciada).

Tabela de diferenças de chave estrangeira

A tabela a seguir lista as diferenças detalhadas entre chaves estrangeiras obrigatórias e informativas:

Chaves estrangeiras aplicadas Chaves externas informativas
Palavras-chave ENFORCED NOT ENFORCED
Compatível com o GoogleSQL Sim. As chaves estrangeiras no GoogleSQL são aplicadas por padrão. Sim.
Compatível com PostgreSQL Sim. As chaves estrangeiras no PostgreSQL só podem ser aplicadas. Não.
Armazenamento As chaves estrangeiras aplicadas exigem armazenamento para até dois índices de backup. As chaves estrangeiras informativas exigem armazenamento para até um índice de aplicação.
Cria índices de suporte nas colunas de tabelas referenciadas quando necessário. Sim. Sim.
Cria índices de suporte em colunas de tabelas de referência quando necessário. Sim. Não.
Compatibilidade com ações de chave estrangeira Sim. Não.
Valida e aplica a integridade referencial Sim. Não. Não ter validação melhora a performance de gravação, mas pode afetar os resultados da consulta quando chaves estrangeiras informacionais são usadas para otimização de consultas. É possível usar a validação do lado do cliente ou uma chave externa aplicada para garantir a integridade referencial.

Escolher o tipo de chave externa a ser usado

Use estas diretrizes para decidir qual tipo de chave externa usar:

Recomendamos que você comece com chaves estrangeiras aplicadas. As chaves estrangeiras aplicadas mantêm os dados e o modelo lógico consistentes em todos os momentos. As chaves estrangeiras aplicadas são a opção recomendada, a menos que não funcionem para seu caso de uso.

Recomendamos que você considere chaves estrangeiras informativas se cada uma das seguintes condições for verdadeira:

  • Você quer usar o modelo de dados lógico descrito pela chave externa informativa na otimização de consultas.

  • Manter uma integridade referencial estrita é impraticável ou afeta significativamente o desempenho. Confira alguns exemplos de quando usar uma chave externa informativa:

    • Sua fonte de dados upstream segue um modelo de consistência eventual. Nesse caso, as atualizações feitas no sistema de origem podem não ser refletidas imediatamente no Spanner. Como as atualizações podem não ser imediatas, podem ocorrer pequenas inconsistências nas relações chave externa.

    • Seus dados contêm linhas referenciadas com um grande número de relacionamentos de referência. As atualizações dessas linhas podem usar muitos recursos porque o Spanner precisa validar ou, em alguns casos, excluir todas as linhas relacionadas à manutenção da integridade referencial. Nesse cenário, as atualizações podem afetar a performance do Spanner e diminuir a velocidade das transações simultâneas.

  • Seu aplicativo pode processar possíveis inconsistências de dados e o impacto delas nos resultados da consulta.

Usar chaves estrangeiras informativas

Os tópicos a seguir são apenas para chaves estrangeiras informativas. Para tópicos que se aplicam a chaves externas informativas e aplicadas, consulte o seguinte:

Criar uma tabela com uma chave externa informativa

Você cria e remove chaves estrangeiras informativas do banco de dados do Spanner usando instruções DDL. As chaves estrangeiras são adicionadas a uma nova tabela com a instrução CREATE TABLE. Da mesma forma, é possível adicionar ou remover chaves estrangeiras de uma tabela atual com a instrução ALTER TABLE.

O exemplo a seguir cria uma tabela com uma chave externa informativa usando o GoogleSQL. As chaves externas informativas não são compatíveis com o PostgreSQL.

GoogleSQL 

CREATE TABLE Customers (
  CustomerId INT64 NOT NULL,
  CustomerName STRING(MAX) NOT NULL,
) PRIMARY KEY(CustomerId);

CREATE TABLE Orders (
  OrderId INT64 NOT NULL,
  CustomerId INT64 NOT NULL,
  Quantity INT64 NOT NULL,
  ProductId INT64 NOT NULL,
  CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerId)
   REFERENCES Customers (CustomerId) NOT ENFORCED
 ) PRIMARY KEY (OrderId);

PostgreSQL 

Not Supported

Para mais exemplos de como criar e gerenciar chaves estrangeiras, consulte Criar e gerenciar chave externa estrangeiras. Para mais informações sobre instruções DDL, consulte a referência de DDL.

Usar chaves estrangeiras informativas para otimizar consultas

As chaves estrangeiras obrigatórias e informativas podem ser usadas pelo otimizador de consultas para melhorar o desempenho. Usar chaves externas informativas permite aproveitar planos de consulta otimizados sem a sobrecarga da aplicação estrita da integridade referencial.

Se você ativar o otimizador de consultas para usar informações de chaves estrangeiras informativas, é importante entender que a correção da otimização depende de dados consistentes com o modelo lógico descrito pelas chaves estrangeiras informativas. Se houver inconsistências, os resultados da consulta poderão não refletir os dados reais. Por exemplo, quando um valor em uma coluna restrita não tem um valor correspondente em uma coluna referenciada.

Por padrão, o otimizador de consultas usa chaves estrangeiras NOT ENFORCED. Para mudar isso, defina a opção de banco de dados use_unenforced_foreign_key_for_query_optimization como "false". Confira a seguir um exemplo em GoogleSQL que demonstra isso. As chaves estrangeiras informativas não estão disponíveis no PostgreSQL.

SET DATABASE OPTIONS (
    use_unenforced_foreign_key_for_query_optimization = false
);

A dica de instrução de consulta booleana @{use_unenforced_foreign_key} substitui a opção de banco de dados por consulta, que controla se o otimizador usa chaves estrangeiras NOT ENFORCED. Desativar essa dica ou a opção do banco de dados pode ser útil ao resolver problemas com resultados inesperados de consultas. Confira a seguir como usar @{use_unenforced_foreign_key}:

@{use_unenforced_foreign_key=false} SELECT Orders.CustomerId
    FROM Orders
    INNER JOIN Customers ON Customers.CustomerId = Orders.CustomerId;

Usar chaves estrangeiras obrigatórias

Os tópicos a seguir são apenas para chaves estrangeiras aplicadas. Para tópicos que se aplicam a chaves externas informativas e aplicadas, consulte o seguinte:

Criar uma nova tabela com uma chave externa aplicada

Você cria, remove e aplica chaves estrangeiras do banco de dados do Spanner usando DDL. As chaves estrangeiras são adicionadas a uma nova tabela com a instrução CREATE TABLE. Da mesma forma, você adiciona ou remove uma chave externa de uma tabela atual com a instrução ALTER TABLE.

Você cria e remove chaves estrangeiras do banco de dados do Spanner usando DDL. As chaves estrangeiras são adicionadas a uma nova tabela com a instrução CREATE TABLE. Da mesma forma, você adiciona ou remove uma chave externa de uma tabela atual com a instrução ALTER TABLE.

Confira a seguir um exemplo de como criar uma nova tabela com uma chave externa aplicada.

GoogleSQL 

CREATE TABLE Customers (
CustomerId INT64 NOT NULL,
CustomerName STRING(MAX) NOT NULL,
) PRIMARY KEY(CustomerId);

CREATE TABLE Orders (
OrderId INT64 NOT NULL,
CustomerId INT64 NOT NULL,
Quantity INT64 NOT NULL,
ProductId INT64 NOT NULL,
CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerId)
  REFERENCES Customers (CustomerId) ENFORCED
) PRIMARY KEY (OrderId);

PostgreSQL 

CREATE TABLE Customers (
CustomerId bigint NOT NULL,
CustomerName character varying(1024) NOT NULL,
PRIMARY KEY(CustomerId)
);

CREATE TABLE Orders (
OrderId BIGINT NOT NULL,
CustomerId BIGINT NOT NULL,
Quantity BIGINT NOT NULL,
ProductId BIGINT NOT NULL,
CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerId)
  REFERENCES Customers (CustomerId),
PRIMARY KEY (OrderId)
);

Para mais exemplos de como criar e gerenciar chaves estrangeiras, consulte Criar e gerenciar chave externa estrangeiras.

Ações de chave externa

As ações de chave estrangeira só podem ser definidas em chaves estrangeiras aplicadas.

As ações de chave estrangeira controlam o que acontece com a coluna restrita quando a coluna referenciada é excluída ou atualizada. O Spanner oferece suporte ao uso da ação ON DELETE CASCADE. Com a ação de chave externa ON DELETE CASCADE, quando você exclui uma linha que contém uma chave externa referenciada, todas as linhas que fazem referência a essa chave também são excluídas na mesma transação.

É possível adicionar uma chave externa com uma ação ao criar o banco de dados usando DDL. Use a instrução CREATE TABLE para adicionar chaves estrangeiras com uma ação a uma nova tabela. Da mesma forma, é possível usar a instrução ALTER TABLE para adicionar ou remover uma ação chave externa de uma tabela. Confira a seguir um exemplo de como criar uma nova tabela com uma ação chave externa.

GoogleSQL 

CREATE TABLE ShoppingCarts (
CartId INT64 NOT NULL,
CustomerId INT64 NOT NULL,
CustomerName STRING(MAX) NOT NULL,
CONSTRAINT FKShoppingCartsCustomers FOREIGN KEY(CustomerId, CustomerName)
  REFERENCES Customers(CustomerId, CustomerName) ON DELETE CASCADE,
) PRIMARY KEY(CartId);

PostgreSQL 

CREATE TABLE ShoppingCarts (
CartId bigint NOT NULL,
CustomerId bigint NOT NULL,
CustomerName character varying(1024) NOT NULL,
PRIMARY KEY(CartId),
CONSTRAINT fkshoppingcartscustomers FOREIGN KEY (CustomerId, CustomerName)
  REFERENCES Customers(CustomerId, CustomerName) ON DELETE CASCADE
);

Confira a seguir uma lista de características das ações de chave externa no Spanner.

  • As ações de chave estrangeira são ON DELETE CASCADE ou ON DELETE NO ACTION.

  • É possível consultar o INFORMATION_SCHEMA para encontrar restrições de chave externa que têm uma ação.

  • Não é possível adicionar uma ação de chave externa a uma restrição de chave externa. Você precisa adicionar uma nova restrição chave externa com uma ação.

Validação de restrição

A validação de restrições se aplica apenas a chaves estrangeiras aplicadas.

O Spanner valida as restrições de chave externa aplicadas quando uma transação é confirmada ou quando os efeitos das gravações são visíveis para operações subsequentes na transação.

Um valor inserido na coluna de referência é comparado com os valores da tabela referenciada e das colunas referenciadas. As linhas com valores de referência NULL não são verificadas, o que significa que você pode adicioná-las à tabela de referência.

O Spanner valida todas as restrições de referência de chave externa aplicáveis ao tentar atualizar dados usando instruções DML ou uma API. Todas as mudanças pendentes serão revertidas se alguma restrição for inválida.

A validação ocorre imediatamente após cada instrução DML. Por exemplo, é preciso inserir a linha referenciada antes de inserir as linhas de referência. Ao usar uma API de mutação, as mutações são armazenadas em buffer até que a transação seja confirmada. A validação de chave externa aplicada é adiada até que a transação seja confirmada. Nesse caso, é permitido inserir primeiro as linhas de referência.

Cada transação é avaliada quanto a modificações que afetam as restrições de chave estrangeira aplicadas. Essas avaliações podem exigir outras solicitações ao servidor. Os índices de backup também exigem mais tempo de processamento para avaliar as modificações de transação e manter os índices. O armazenamento extra também é necessário para cada índice.

Ação de exclusão em cascata de longa duração

Quando você exclui uma linha de uma tabela referenciada, o Spanner precisa excluir todas as linhas das tabelas de referência que fazem referência à linha excluída. Isso pode levar a um efeito cascata, em que uma única operação de exclusão resulta em milhares de outras operações de exclusão. Adicionar uma restrição chave externa com ação de exclusão em cascata a uma tabela ou criar uma tabela com restrições chave externa com ação de exclusão em cascata pode diminuir a velocidade das operações de exclusão.

O limite de mutação foi excedido para exclusão em cascata de chave externa

Excluir um grande número de registros usando uma exclusão em cascata de chave externa pode afetar o desempenho. Isso acontece porque cada registro excluído invoca a exclusão de todos os registros relacionados a ele. Se você precisar excluir um grande número de registros usando uma exclusão em cascata de chave externa, exclua explicitamente as linhas das tabelas filhas antes de excluir a linha das tabelas principais. Isso evita que a transação falhe devido ao limite de mutação.

Comparação de chaves externas aplicadas e intercalação de tabelas

A intercalação de tabelas do Spanner é uma boa opção para muitas relações pai-filho em que a chave primária da tabela filha inclui as colunas de chave primária da tabela pai. A colocalização das linhas filhas com as linhas mãe pode melhorar bastante o desempenho.

As chaves externas são uma solução pai-filho mais geral e abordam casos de uso adicionais. Elas não estão limitadas a colunas de chave primária, e as tabelas podem ter várias relações de chave externa, como pai em alguns relacionamentos e filho em outros. No entanto, uma relação de chave estrangeira não sugere a colocalização das tabelas na camada de armazenamento.

Considere um exemplo que usa uma tabela Orders definida da seguinte maneira:

Esquema do banco de dados com chaves estrangeiras

Figura 3. Diagrama do esquema de banco de dados com chaves estrangeiras aplicadas

O design na Figura 3 tem algumas limitações. Por exemplo, cada pedido pode conter apenas um item.

Imagine que seus clientes querem pedir mais de um produto por pedido. Você pode melhorar seu design introduzindo uma tabela OrderItems que contenha uma entrada para cada produto solicitado pelo cliente. Você pode introduzir outra chave externa obrigatória para representar essa nova relação de um para muitos entre Orders e OrderItems. No entanto, você também sabe que muitas vezes é necessário executar consultas entre os pedidos e os respectivos itens de pedido. Como a colocalização desses dados aumenta o desempenho, crie a relação pai-filho usando o recurso de intercalação de tabelas do Spanner.

Veja como definir a tabela OrderItems, intercalada com Orders.

GoogleSQL 

CREATE TABLE Products (
ProductId INT64 NOT NULL,
Name STRING(256) NOT NULL,
Price FLOAT64
) PRIMARY KEY(ProductId);

CREATE TABLE OrderItems (
OrderId INT64 NOT NULL,
ProductId INT64 NOT NULL,
Quantity INT64 NOT NULL,
FOREIGN KEY (ProductId) REFERENCES Products (ProductId)
) PRIMARY KEY (OrderId, ProductId),
INTERLEAVE IN PARENT Orders ON DELETE CASCADE;

PostgreSQL 

CREATE TABLE Products (
ProductId BIGINT NOT NULL,
Name varchar(256) NOT NULL,
Price float8,
PRIMARY KEY(ProductId)
);

CREATE TABLE OrderItems (
OrderId BIGINT NOT NULL,
ProductId BIGINT NOT NULL,
Quantity BIGINT NOT NULL,
FOREIGN KEY (ProductId) REFERENCES Products (ProductId),
PRIMARY KEY (OrderId, ProductId)
) INTERLEAVE IN PARENT Orders ON DELETE CASCADE;

A Figura 4 é uma representação visual do esquema de banco de dados atualizado como resultado da introdução dessa nova tabela, OrderItems, intercalada com Orders. Aqui você também pode ver a relação de um para muitos entre essas duas tabelas.

Esquema do banco de dados que mostra uma relação de um para muitos entre pedidos e a nova tabela intercalada, "OrderItems"

Figura 4. Adição de uma tabela intercalada "OrderItems"

Nessa configuração, é possível ter várias entradas OrderItems em cada pedido, e as entradas OrderItems de cada pedido são intercaladas e, portanto, colocalizadas com os pedidos. Intercalar fisicamente Orders e OrderItems dessa maneira pode melhorar o desempenho, mesclando previamente as tabelas e permitindo que você acesse linhas relacionadas, ao mesmo tempo que minimiza os acessos ao disco. Por exemplo, o Spanner pode realizar junções por chave primária localmente, minimizando o acesso ao disco e o tráfego de rede.

Se o número de mutações em uma transação exceder 80.000, a transação vai falhar. Essas exclusões em cascata grandes funcionam bem para tabelas com uma relação "intercalada no pai", mas não para tabelas com uma relação de chave externa. Se você tiver uma relação chave externa e precisar excluir um grande número de linhas, exclua explicitamente as linhas das tabelas filhas primeiro.

Se você tiver uma tabela de usuários com uma relação de chave externa com outra tabela e a exclusão de uma linha da tabela referenciada acionar a exclusão de milhões de linhas, crie seu esquema com uma ação de exclusão em cascata com "intercalada no pai".

Tabela de comparação

A tabela a seguir mostra um resumo comparando as chaves estrangeiras aplicadas e a intercalação de tabelas. Use essas informações para decidir o que é melhor para seu projeto.

Tipo de relação pai-filho Intercalação de tabelas Chaves estrangeiras aplicadas
Pode usar chaves primárias Sim Sim
Pode usar colunas não primárias Não Sim
Número de pais compatíveis 0 .. 1 0 .. N
Armazena dados pai e filho juntos Sim Não
Compatível com exclusão em cascata Sim Sim
Modo de correspondência nulo Aprovado se todos os valores de referênciaforem iguais aos valores referenciados.
Valores nulos não são diferentes de valores nulos. Os valores nulos são diferentes dos valores não nulos.		 Aprovado se algum valor de referência for nulo.
Aprovado se todos os valores de referência não forem nulos e a tabela referenciada tiver uma linha com valores iguais aos valores de referência.
Ocorre uma falha se nenhuma linha correspondente for encontrada.
Tempo de aplicação Por operação ao usar a API de mutação.
Por instrução ao usar DML.		 Por transação ao usar a API de mutação.
Por instrução ao usar DML.
Pode ser removido Não. Não é possível remover a intercalação de tabelas após a criação, a menos que você exclua a tabela filha inteira. Sim

Índices de backup

As chaves estrangeiras não usam índices criados pelo usuário. Em vez disso, elas criam seus próprios índices de backup. As chaves externas aplicadas e informativas criam índices de backup de maneira diferente no Spanner:

  • Para chaves estrangeiras aplicadas, o Spanner pode criar até dois índices de backup secundários para cada chave externa: um para as colunas de referência e um segundo para as colunas referenciadas.

  • Para chaves externas informativas, o Spanner pode criar até um índice de aplicação quando necessário para as colunas referenciadas. As chaves estrangeiras informativas não criam um índice de aplicação para as colunas de referência.

Para chaves estrangeiras aplicadas e informativas, uma chave externa geralmente faz referência às chaves primárias da tabela referenciada. Portanto, um índice para a tabela referenciada normalmente não é necessário. Por isso, as chaves externas informativas geralmente não têm índices de backup. Quando necessário, o índice de aplicação criado para a tabela referenciada é um índice UNIQUE NULL_FILTERED. A criação da chave externa falhará se algum dado violar a restrição de exclusividade do índice.

As chaves externas informativas não têm um índice de aplicação para a tabela de referência. Para chaves externas aplicadas, o índice de aplicação da tabela de referência é NULL_FILTERED.

Se duas ou mais chaves externas exigirem o mesmo índice de aplicação, o Spanner vai criar um único índice para cada uma delas. Os índices de backup são descartados quando as chaves estrangeiras que os utilizam são descartadas. Não é possível alterar ou descartar os índices de backup.

O Spanner usa o esquema de informações de cada banco de dados para armazenar metadados sobre índices de aplicação. As linhas em INFORMATION_SCHEMA.INDEXES que têm um valor SPANNER_IS_MANAGED de true descrevem os índices de suporte.

Fora das consultas SQL que invocam diretamente o esquema de informações, o console do Google Cloud não mostra informações sobre os índices de suporte de um banco de dados.

Alterações de esquema de longa duração

Adicionar uma chave externa aplicada a uma tabela atual ou criar uma nova tabela com uma chave externa pode levar a operações de longa duração. No caso de uma nova tabela, ela não pode ser gravada até que a operação de longa duração seja concluída.

A tabela a seguir mostra o que acontece no Spanner quando uma chave externa obrigatória e uma informativa estão em uma tabela nova ou existente:

Tipo de tabela Chave externa aplicada Chave externa informativa
Novo O Spanner preenche os índices referenciados conforme necessário para cada chave externa. O Spanner preenche os índices referenciados conforme necessário para cada chave externa.
Atual O Spanner preenche os índices de referência e referenciados conforme necessário. O Spanner também valida os dados atuais na tabela para garantir a conformidade com a restrição de integridade referencial da chave externa. A mudança de esquema falha se houver dados inválidos. O Spanner preenche o índice referenciado conforme necessário e não valida os dados atuais na tabela.

Não há compatibilidade com os seguintes recursos:

  • Adicionar uma ação de chave externa a uma restrição de chave externa aplicada.
  • Mudar a aplicação de uma chave externa.

Para ambos os casos, recomendamos que você faça o seguinte:

  1. Adicione uma nova restrição com a ação ou aplicação necessária.
  2. Remova a restrição antiga.

Adicionar uma nova restrição e remover a antiga evita um problema de operação de alteração de restrição de longa duração. Por exemplo, suponha que você queira adicionar uma ação DELETE CASCADE a uma chave externa. Depois de criar a nova chave externa com a ação ON DELETE CASCADE, o efeito de ambas as restrições é uma ação DELETE CASCADE. Em seguida, é possível descartar a restrição antiga com segurança.

A remoção de uma restrição pode levar à remoção dos índices de backup de chave externa se eles não forem usados por outras restrições de chave externa. Por isso, se você remover a restrição antiga primeiro, adicionar a mesma restrição de chave externa com uma ação depois poderá levar a operações de longa duração, como preenchimento de índices, validação de restrições de índice exclusivo ou validação de restrições referenciais de chave externa.

Você pode consultar INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS.SPANNER_STATE para verificar o estado da criação de chave externa.

A seguir