Critica na exlusão de um registro com dependência

Sugestões
#1

Hoje existem 2 opções:

  • Excluir as dependências;
  • Criticar e não permitir, caso exista dependência.

Mas existem casos que realmente queremos excluir com a dependência. Mas se no desenvolvimento eu marquei que é para não permitir, sou obrigado a excluir 1 por 1 as dependências, antes de excluir o registro PAI.

Minha sugestão, seria ou ajustar a opção de critica ou criar uma 3 opção, aonde seria informado que existem dependências, mas dando a opção de excluir automaticamente essas dependências.

#2

A tua descrição ocorre sob a camada da aplicação. Crie uma função que executa sob a camada do banco de dados e coloque a chamada em um botão.

Ex: excluir_pai_e_filhos();

CREATE OR REPLACE FUNCTION excluir_pai_e_filhos(p_id_pai INT)
RETURNS VOID AS $$
BEGIN
– Exclui primeiro os registros na tabela filhos (se necessário)
DELETE FROM Filhos WHERE id_pai = p_id_pai;

 -- Exclui o registro da tabela pai
DELETE FROM Pai WHERE id = p_id_pai;

END;
$$ LANGUAGE plpgsql;

Att, Paulo.

#3

Ao invés de eu ter que criar mais um botão, e implementar em todas as telas que preciso desse recurso, não é mais produtivo se a ferramenta me der esse recurso (aliás adicionar essa funcionalidade dentro de um recurso que ela já me fornece)?

2 Curtidas
#4

Dependendo das regras de negócio e das especificações de projeto é muito mais útil e escalável usar os recursos do banco (functions, trigger, etc) do que os da aplicação.

#5

Eu, particularmente aboli regras de negócio no banco de dados. Banco de dados para mim para popular e extrair dados. Nem Foreign Key eu utilizo.

Hoje utilizo uma camada na própria linguagem entre aplicação e banco de dados,

Mas o @amnalon tem razão, a questão é diretamente na aplicação em um recurso nativo da aplicação.

1 Curtida
#6

Concordo. O uso de banco de dados não tipados, força o desenvolvedor a usar camadas da aplicação, o inverso nem tanto.

#7

Estas dependências permitem delete usando cascade?

#8

Padrão MVC.

Evita expor as regras de negócio a quem tem acesso ao banco de dados.

E em muitos projetos o programador não tem permissão para alterar o banco.

E dependendo da comercialização o Cliente exige que o banco de dados dele esteja em servidores próprios.

Em grandes equipes de desenvolvimento, geralmente o programador só tem acesso as regras de negócio ao qual compete sua abrangência no desenvolvimento.

1 Curtida