Restrição assertiva em banco vs Regra de negócio no código

[rafael_indiao 0]

Olá a todos.

Relendo sore banco de dados me deparei com a seguinte citação do livro Sistema de Banco de Dados, do Abraham Silbberschatz, Henry F. Korth e S. Sudarshan:

"Assertivas: Uma assertiva é qualquer condição que o banco de dados sempre precisa satisfazer. As restrições de domínio e as restrições de integridade referencial são formas especiais de assertivas. Todavia, existem muitas restrições que não podemos expressar usando apenas essas formas especiais. Por exemplo, "Cada departamento deve ter pelo menos cinco cursos oferecidos a cada semestre" precisa ser expresso como assertiva. Quando uma assertiva é criada, o sistema testa sua validade. Se a assertiva for válida, qualquer futura modificação no banco de dados só será permitida se ela não fizer com que essa assertiva seja violada." (p.7)

Bom tenho um certo tempo na área de programação e esse tipo de restrição sempre vi inserida no código, mas no livro estou vendo que, ao meu ver, é preferencialmente bom colocar as restrições no banco. O que não deixa de ser uma grande parte da regra de negócios do sistema de uma empresa.

O que vcs acham com esta citação do banco? De colocar as restrições no banco. Ou preferem colocar no código?

[]'s

[Motta 645]

Depende , um exemplo um ERP tem de suportar vários BDs é colocarvesta regra no Banco não é boa estratégia pois demandaria diversos códigos diferentes pois cada BD tem suas particularidades , em um sistema proprietário já pode ser uma prática viável , mas se a empresa quiser mudar o fornecedor de BD muito código precisará ser reescrito , depende.

[rafael_indiao 0]

@Motta, boa tarde, tudo bom?

 

Analisando sua resposta, adicionando conversas na empresa que trabalho e a experiencia que tenho, conclui que:

 

Contras:

 

1 - Quando se trata de um sistema de grande porte, como ERP de uma grande empresa, deixar as restrições no Banco é inviável pois cada banco tem suas particularidades.

2 - O controle de alterações dessas restrições teria de ser muito eficiente, pois mudando uma restrição que não deveria ser alterada e procurar o motivo de tal alteração não torna a resolução do problema um dos mais fáceis ( o rolback de uma rega poderia impactar em diversas área do negócio)

3 - Os softwares tem condições melhores de tratar tais restrições do que em banco, visto que uma restrição pode demandar um custo muito alto para o banco e a aplicação já poderia ter tais informações.

 

Prós

 

1 - Se tratando de informação e do produto que gerencia suas informações iria aumentar seu valor de negócio, visto que uma eventual troca de um SGBD faria com que este tipo de restrição levaria muito em consideração na hora da decisão.

2 - Se houver uma eventual troca de aplicação, por exemplo desktop para web, seria menos trabalhoso para os desenvolvedores de software traduzir as regras para a nova aplicação.

 

Finalizando: Realmente depende do propósito de armazenar as restrições, pois pode ser uma grande oportunidade de sucesso como também oportunidade de arranjar uma bela dor de cabeça para um belo final de semana que pede uma praia.

 

[]'s

[Motta 645]

Um exemplo , uma constraint de um campo xpto teste se o valor deve estar entre 37 e 4237 , um belo dia uma aplicação nova , feita às pressas , em web , entra em produção num feriado como o de hoje , uma condição mal testada tenta gravar 17 neste campo , este campo fora dos parametros dá um erro colussal na rotina de gangazumbamento , vital para empresa, no cenário 1 explodiria um erro feio no usuário mas a integridade seria mantida , no cenário 2 só no pior momente seria visto ...

 

Costumo definir as regras de integridade no banco como o zagueirão da sobra no futebol , ao menos faz a falta .... :)