Início / dba / Perguntas / 39659
Accepted
Max
Asked: 2013-04-11 07:20:53 +0800 CST

Existe uma solução alternativa para a falta de suporte de gatilhos em cascata com o MySQL?

  • 772

Do jeito que as coisas estão, as ações de chave estrangeira em cascata não ativam gatilhos com MySQL. Não quero entrar no debate se isso é bom ou não, só gostaria de saber se existe uma solução alternativa para isso.

Atualmente estou usando triggerspara fazer algo assim:

CREATE TRIGGER `Set_field1_on_update` BEFORE UPDATE ON `mytable`
FOR EACH ROW BEGIN
    SET NEW.field1 =  CONCAT(NEW.myforeignkey,'whatever');
END

O que funciona bem quando myforeignkeyé alterado diretamente, mytablemas não quando é atualizado por ON UPDATE CASCADEmeio de sua tabela referenciada.

Existe alguma maneira de obter a funcionalidade acima (usando algo diferente de gatilhos, se necessário) em ações de chave estrangeira em cascata?

mysql trigger

1 respostas

  1. Best Answer

    A solução alternativa, se essa é a palavra certa para isso, parece que seria fazer as mesmas alterações na tabela filho em um AFTER UPDATEgatilho na tabela pai, contendo a mesma lógica do BEFORE UPDATEgatilho na tabela filho, encapsulado em um teste para faça algo apenas se a chave primária na tabela pai tiver realmente mudado, o que teria causado uma atualização em cascata.

    DELIMITER $$
CREATE TRIGGER parent_after_update AFTER UPDATE ON parent_table FOR EACH ROW
BEGIN

# not using null-safe <=> comparison since PK cannot be null

IF NEW.primary_key != OLD.primary_key THEN

  UPDATE child_table ct
     SET /* the same logic that's in the before update trigger on the child table */
   WHERE ct.parent_primary_key = NEW.primary_key;

END IF;
END $$
DELIMITER ;

    Se a primary_key na parent_table acabou de ser alterada, então, por definição, todas as linhas child_table com o novo valor em sua coluna parent_primary_key devem ter sido atualizadas por meio de uma atualização em cascata, porque até que esse valor exista na parent_table.primary_key, não poderia ter havido quaisquer linhas já existentes com o novo valor em child_table.parent_primary_key ... até que a primary_key da tabela pai fosse atualizada agora, essas linhas não poderiam existir, pois teriam violado a restrição referencial da chave estrangeira (referindo-se a um valor inexistente ).

    Claro, estou usando "chave primária" aqui quando, na realidade, a chave estrangeira pode fazer referência a qualquer superchave da tabela pai.

    No entanto, isso questiona o que você realmente está usando as atualizações em cascata para realizar em primeiro lugar e se essa aplicação de atualizações em cascata constitui um design sólido. Você parece estar derivando outra coluna do valor e armazenando essa coluna derivada, e ambas parecem práticas abaixo do ideal.

    Normalmente, uma atualização em cascata, pelo menos em princípio, se não de fato, parece algo que não é uma alteração nos dados, como seria uma atualização que alterasse a tabela filho diretamente. "Esses" registros filhos fazem referência a "essa" linha na tabela pai. Após uma atualização em cascata, eles ainda o fazem e nada mudou, apenas a chave é diferente.

    • 3

relate perguntas