Validação: no Banco ou na Aplicação?

[Tiago Sabadini 3]

Olá Pessoal, gostaria de saber a opinião de vocês sobre esta questão. Quais tipos de validações ficam no banco e quais vão na aplicação?

 

Não estou falando de validação de formulário, se um cpf é um cpf válido ou não. Essas são básicas e sabemos que é melhor serem feitas com javascript e se tiver no server-side também é bom.

 

Vou dar um exemplo:

Tenho dois perfis em um sistema: Assinante Premium (Acessa artigos completos e avançados) e Assinante Basic (acessa apenas resumos dos artigos avançados e acessa artigos públicos)

 

Acesso o sistema como Assinante Basic, clico no link (Listar todos os artigos) onde é melhor filtrar os dados? Na aplicação? (pegando pelo perfil do usuário que está na sessão) ou fazer isso no banco (dentro do select)?

 

-- Passar essa responsabilidade para o banco, sendo que pode facilmente ser feita pela aplicação não é exagero? Igual passar uma validação de formulário para o servidor quando pode ser feita facilmente pelo javascript?

 

-- Consome mais processamento fazer isso no banco?

 

-- É mais seguro fazer no banco do que fazer na aplicação?

 

Se vocês souberem de artigos com estas informações (talvez padrões de desenvolvimento) podem me passar que estou muito interessado no assunto.

 

Aguardo a ajuda de vocês.

[Maykonn 6]

Eu criaria uma função no banco de dados, onde você informaria nos parâmetros o ID do usuário. Então, essa função faria o necessário para obter o tipo de assinatura do usuário e os dados necessários. Por exemplo, uma função que retorne os artigos disponíveis para um Assinante Premium. Na minha opinião ajuda até mesmo a aplicação ser mais legível.

 

Não sei se estou certo em relação a processamento, pois não realizei testes, mas muito provavelmente não seria maior do que executar consultas através da aplicação. Até porque a consulta já estaria preparada no banco de dados bastando realizar a chamada da função.

[Eudes. 0]

Normalmente BD é mais rápido do que no app, mas isso depende de muitos fatores e pode ser até irrelevante.

 

Verificação de formulário eu creio que é melhor sempre checar no JS e na app. O seguro morreu de velho.

 

Quanto a validar no BD ou na app acho que depende, por exemplo, muitas vezes ao filtrar diretamente no BD você vai evitar de trazer um monte de dados inúteis para a app que depois ela terá que filtrar, ou seja, isso é perfomance. Por outro lado dependendo as vezes é melhor ter já tudo na app e filtrar por ela, para evitar que você fique indo no BD toda hora quando o usuário, vamos dizer, tiver olhando outra coisa. Também é perfomance

 

Se estando falando de um perfil do usuário, onde você garante que ele vai ter somente o acesso àquelas informações naquele sessão, é melhor que você traga pra sessão dele só aquilo que você sabe que ele vai precisar, ou seja, o filtro já pode existir lá no BD. Creio que isso seja uma boa prática.

[JCMais 75]

Aplicação, deixe o BD apenas para armazenar os dados. Se um dia você mudar a arquitetura da aplicação, e decide, por exemplo, usar outro modo de armazenamento de dados, a tua lógica de validação ainda será válida, pois não é dependente da forma com a qual os dados são armazenados.

[Meneguci 1]

Um artigo interessante abrandando um pouco do assunto.

artigo imasters

[Henrique Barcelos 290]

Normalmente BD é mais rápido do que no app, mas isso depende de muitos fatores e pode ser até irrelevante.

 

Ahn? Tem fontes para afirmar isso???

Não tenho conhecimentos de bancos de dados para dizer que não, mas duvido muito que uma DSL seja mais veloz para validação de dados do que uma linguagem Turing Completa.

O objetivo principal de um banco de dados é ARMAZENAR DADOS, o restante é pura "sobremesa".

[Guilherme_90 33]

Eu acho que tu depende da implementação que cada programador faz. Validar no Banco de Dados não quer dizer que está errado, porém como tudo na vida existe os dois lados da moeda. Você pode fazer isso, mas sofrerá MUITO caso mude de SGBD na sua aplicação, aí tu vai ver a casa cair!

 

Sou da mesma opnião do Henrique Barcerlos e JCMais. Na verdade pensei mais pelo lado que o JCMais disse, pois se o seu objetivo é ter uma aplicação que funcione redondo independente de SGBD, JAMAIS, NUNCA, NEVER faça validações em seu Banco de Dados.

[shini 318]

JAMAIS, NUNCA, NEVER faça validações em seu Banco de Dados

 

depende da linguagem/arquitetura q você esta usando, ja viu como o pessoal do delphi trabalha? 70/80% da logica vai direto no banco, diga-se firebird. Algumas poucas validações pode ser feitas no banco pq diminum linhas de codigo na aplicação, rs qto menos codigo melhor.

 

JAMAIS, NUNCA, NEVER faça validações em seu Banco de Dados

 

depende da linguagem/arquitetura q você esta usando, ja viu como o pessoal do delphi trabalha? 70/80% da logica vai direto no banco, diga-se firebird. Algumas poucas validações pode ser feitas no banco pq diminum linhas de codigo na aplicação, rs qto menos codigo melhor.

[Prog 183]

Acho que depende um pouco do negócio também...

 

Um sistema financeiro, por exemplo, com várias batches e coisas com horas especificas para rodar, várias regras e validações podem ser colocadas no banco de dados, isto também aumenta a segurança e confiabilidade dos dados.

 

Quando dizem que um banco de dados é mais veloz, bem, isto esta relacionado principalmente a 2 fatores, o primeiro é que um equipamento com banco de dados comumente é instalado no melhor do melhor numa infra-estrutura de computadores (se o caso aqui for um sistema de hospedagem compartilhada ou coloca naquele pentium 2, já não serve mais), o outro fator é o tráfego de rede e api, certamente uma instrução com operações dentro do próprio banco de dados será mais veloz que qualquer outro que precise passar por uma api e sofra interferencia de latência de trasmissão de dados.

[Henrique Barcelos 290]

De fato, o Prog abordou um fato bem importante.

Se a validação precisa passar pelo banco de dados de uma forma ou de outra, o ganho de performance pode ser considerável se for feito internamente.

Entretanto, como já disseram, há uma certa perda de portabilidade, visto que as linguagens procedurais de cada SGBD são MUITO diferentes entre si.

 

A resposta é que não há resposta, tudo depende do contexto...

[Eudes. 0]

Prog já disse tudo e você mesmo Henrique já complementou a resposta da pergunta que me fez.

 

No BD, acaba sendo muito mais rápido ter a regra de negócio lá em muitas situações, especialmente quando se tem muitos dados para serem tratados. Se a app não receber muita coisa, ou seja, o BD já der tudo filtrado, o app terá muito menos coisa para processar e haverá muito menos dados na sessão da app.

 

Quanto a mudança de SGBD, boa parte do trabalho pode ser resolvida dependendo da arquitetura que foi usada.