Carregando...

Refine ainda mais o processo de integridade das suas informações no PostgreSQL

Refine ainda mais o processo de integridade das suas informações no PostgreSQL
Por: Mario Marcio S. Santos
Publicado em: 18:04:2018

Depois dos relacionamentos você pode se deparar com outro tipo de dificuldade, mas a solução para esse problema é mais simples do que você pode imaginar

Salve salve webmaster! Gustavo Web aqui mais uma vez.

Se lembra que na semana passada falamos sobre relacionamentos no PostgreSQL? Vimos de forma bem simples que com apenas um passo você consegue adicionar um gatilho para auxiliar na integridade das suas informações!

Caso você você não tenha assistido o conteúdo, prende o dedo aqui no link que eu te levo pra lá agora para você conferir o conteúdo. É bem importante que você assista essa primeira aula para que tudo faça um maior sentido para você!

Isso sem contar também, que se você seguir o passo a passo junto comigo na aula anterior, vai ficar mais fácil de fazer os exercícios dessa aula, fechado?

Bom, o conteúdo dessa aula eu mostro quais são as possibilidades para utilizar junto com o comando ON DELETE, que como você consegue conferir no vídeo são 5! Maaas, como sou bonzinho, vou colocar um resumo em texto aqui para auxiliar nos estudos :)

5 opções para usar no ON DELETE

Confere aqui quais são as opções que você tem disponível para trabalhar e um breve resumo de cada uma delas.

NO ACTION

Esse é o valor padrão! Se você não especificar o ON DELETE na criação da sua tabela, esse será o comportamento padrão que será adotado.

Como o próprio nome diz ele não tem ação nenhuma, simplesmente é ignorado o comando (para a tabela filha) e por consequência o registro (da tabela filha) continua existindo... Com isso, a restrição não será satisfeita e você terá como resultado uma mensagem de erro lhe informando que esse tipo de ação não é permitido porque há relacionamentos pendentes.

RESTRICT

Basicamente tem o mesmo comportamento do NO ACTION, a diferença é que ele não adia a verificação das restrições. Aí a gente começa a entrar num assunto beeeem mais avançado que isso só faria diferença se você estivesse dentro de uma transação. Então por hora, vamos pular esse comportamento.

Só um adendo: Pode ser que você esteja vendo essa página justamente para saber a diferença entre eles. Se for isso, li num fórum certa vez que um motivo plausível para usar esse tipo de recurso seria basicamente se você estivesse dentro de uma transação (numa function, procedure, trigger...) e você precisasse deletar o registro que é a base de tudo (no nosso exemplo da aula seria o usuário) e logo depois criar um registro com o mesmo valor na chave (com o mesmo id) e vincular todos os registros filhos a esse novo que foi criado.

Sei lá, não poderia simplesmente ser um UPDATE em todas as colunas? :P

SET DEFAULT

Com essa instrução, quando ocorrer um DELETE na tabela principal (no caso a tabela de usuários) o campo da sua tabela filha ficará com o valor que foi definido por padrão. Nesse caso, você pode informar um valor padrão para o campo e é esse mesmo valor que será colocado no lugar!

Importante: A verificação de restrição continuará acontecendo! Logo, não adianta você tentar colocar qualquer valor, ou um valor exorbitante... Se ele não existir na tabela de referência você terá o erro da mesma forma.

SET NULL

Bem óbvio também né! Uma particularidade aqui desse caso é que você pode setar o valor do campo como nulo e não terá mensagem de erro (mesmo a restrição não sendo satisfeita). Nesse caso, você pode estudar o MATH FULL, que é uma outra sintaxe que vai tratar esses casos.

CASCADE

Na minha visão, a melhor alternativa que temos até o momento para de fato limpar tudo o que estiver relacionado com o registro principal. Assim como falei na aula, o ideal é que você tenha todos os tratamentos sendo feitos dentro da sua aplicação e esse gatilho é para garantir a integridade. Deve-se tomar muito cuidado esse tipo de recurso e inclusive ponderar onde e como deve ser adicionado dentro da sua modelagem... Na aula eu até mostro um exemplo do que aconteceria se você tiver todos os relacionamentos possíveis dentro do sistema!

Como tratar os UPDATES

Assim como existe o ON DELETE há também o ON UPDATE, inclusive as mesmas opções que você tem para um, você tem para o outro. No geral uma forma de se trabalhar é usar o NO ACTION para o UPDATE e o CASCADE para DELETE. Com isso você tem uma configuração legal para rodar o seu sistema e trabalhar bem a sua modelagem :)

Seu dever agora...

É claro que é fortalecer nossa forma de comunicação! Vou te passar o passo a passo :)

Já está na nossa lista VIP? Se não, está esperando o que? Clica aqui agora e se cadastra!

Já assinou nosso canal do YouTube? Clica aqui e eu já vou abrir a popupzinha para você se inscrever!

Já deixou o seu "Gostei/Não Gostei" no vídeo? Acessa a aula lá no YouTube e clica lá pra gente saber o que você está achando do conteúdo!

E já sabe, se quiser conversar comigo, você pode usar os comentários aqui abaixo ou lá no próprio YouTube.

Forte abraço.

Relacionados:

Confira mais conteúdo e aumente seu arsenal de comunicação!