Validação de CPF e CNPJ
10/03/2015
0
Em que situações deve ser feito tanto na aplicação como no banco?
Mariana Carvalho
Post mais votado
16/03/2015
Ao encapsular regras de negócio no banco de dados você dificulta a migração para outros bancos de dados.
Quando todas a regras de negócio ficam na aplicação você dá atomicidade a mesma o que a torna mais legível e de fácil manutenção.
Agora só com informação segue scripts sql para executar a validação.
CPF:
/*
Calculo do Digito Verificador para CPF
por: Antonio Rodrigues dos Santos Filho - antonio@aikon.com.br
Instruções
1- O CPF deve ser passado contendo apenas os numero. Não coloque os '.' e '/'
2- O resultado da função será o Digito Verificador em char(2)
Exemplo:
declare @dv as char(2)
set @dv = dbo.CalculaCPF ('123456789')
print @dv
obs: Neste caso o DV = 09
qualquer erro, o resultado do DV será --
*/
create function dbo.CalculaCPF (@cpf as varchar(10))
returns char(2)
as
Begin
declare @soma as int,
@dv as char(2),
@dv1 as int,
@dv2 as int,
@i as int,
@somando as int
set @cpf = substring(@cpf, 1, 9)
set @dv = '--'
-- Teste 1. O cpf nao pode ser tudo 1 ou 2 e etc
if not (@cpf = '111111111' or @cpf = '222222222' or @cpf = '333333333' or @cpf = '444444444' or @cpf = '555555555' or @cpf = '666666666' or @cpf = '777777777' or @cpf = '888888888' or @cpf = '999999999' or @cpf = '000000000')
begin
-- Teste 2. Verifica se o cpf tem os 9 digitos preenchidos
If rtrim(Len(@cpf)) = 9
begin
--Calcula DV1 (1o Digito Verificador)
set @soma = 0
set @somando = 10
set @i = 1
while @i < 10
begin
set @soma = @soma + Substring(@cpf, @i, 1) * @somando
set @somando = @somando - 1
set @i = @i +1
end
set @dv1 = 11 - (@soma - (@soma/11) * 11)
If @dv1 > 9 set @dv1 = 0
-- Calcula DV2 (2o Digito Verificador)
set @cpf = @cpf + ltrim(str(@dv1))
set @soma = 0
set @somando = 11
set @i = 1
while @i < 11
begin
set @soma = @soma + Substring(@cpf, @i, 1) * @somando
set @somando = @somando - 1
set @i = @i +1
end
set @dv2 = 11 - (@soma - (@soma/11) * 11)
If @dv2 > 9 set @dv2= 0
if @dv1 <> 0
begin
set @dv = ltrim(str(@dv1 * 10 + @dv2))
end else begin
set @dv = '0' + ltrim(str(@dv2))
end
End
End
Return (@dv)
End
CNPJ:
/*
Calculo do Digito Verificador para CNPJ
por: Antonio Rodrigues dos Santos Filho - antonio@aikon.com.br
Instruções
1- O CPF deve ser passado contendo apenas os numero. Não coloque os '.' e '/'
2- O resultado da função será o Digito Verificador em char(2)
Exemplo:
declare @dv as char(2)
set @dv = dbo.CalculaCNPJ ('123456780001')
print @dv
obs: Neste caso o DV = 95
qualquer erro, o resultado do DV será --
*/
alter function dbo.CalculaCNPJ (@cnpj as varchar(13))
returns char(2)
as
Begin
declare @soma as int,
@dv as char(2),
@dv1 as int,
@dv2 as int,
@i as int,
@somando as int,
@cnpj1 as char(8)
set @cnpj1 = substring(@cnpj, 1, 8)
set @dv = '--'
-- Teste 1. O cpf nao pode ser tudo 1 ou 2 e etc
if not (@cnpj1 = '11111111' or @cnpj1 = '22222222' or @cnpj1 = '33333333' or @cnpj1 = '44444444' or @cnpj1 = '55555555' or @cnpj1 = '66666666' or @cnpj1 = '77777777' or @cnpj1 = '88888888' or @cnpj1 = '99999999' or @cnpj1 = '00000000')
begin
-- Teste 2. Verifica se o cpf tem os 9 digitos preenchidos
If rtrim(Len(@cnpj)) = 12
begin
--Calcula DV1 (1o Digito Verificador)
set @soma = 0
set @somando = 5
set @i = 1
while @i < 5
begin
set @soma = @soma + Substring(@cnpj, @i, 1) * @somando
set @somando = @somando - 1
set @i = @i +1
end
set @somando = 9
set @i = 5
while @i < 13
begin
set @soma = @soma + Substring(@cnpj, @i, 1) * @somando
set @somando = @somando - 1
set @i = @i +1
end
set @dv1 = 11 - (@soma - (@soma/11) * 11)
If @dv1 > 9 set @dv1 = 0
-- Calcula DV2 (2o Digito Verificador)
set @cnpj = @cnpj + ltrim(str(@dv1))
set @soma = 0
set @somando = 6
set @i = 1
while @i < 6
begin
set @soma = @soma + Substring(@cnpj, @i, 1) * @somando
set @somando = @somando - 1
set @i = @i +1
end
set @somando = 9
set @i = 6
while @i < 14
begin
set @soma = @soma + Substring(@cnpj, @i, 1) * @somando
set @somando = @somando - 1
set @i = @i +1
end
set @dv2 = 11 - (@soma - (@soma/11) * 11)
If @dv2 > 9 set @dv2= 0
if @dv1 <> 0 begin
set @dv = ltrim(str(@dv1 * 10 + @dv2))
end else begin
set @dv = '0' + ltrim(str(@dv2))
end
end
end
return (@dv)
end
Jothaz
Mais Posts
16/03/2015
Thiago Santana
20/03/2015
Mariana Carvalho
20/03/2015
Jothaz
Em TI não existe esta abordagem de 8 ou 80, tudo depende do cenário e principalmente de como o analista/projetista entende que é o mais indicado a fazer. Desde que seja embasado em argumentos técnicos viáveis.
Seguindo as melhores práticas a ideia hoje em dia é colocar toda a regra de negócio dentro da aplicação e eis alguns motivos:
Apesar de atualmente todos os bancos de dados seguirem uma especificação padrão (se não me engando SQL-92) cada banco possui suas peculiaridade e especificidades com relação a funções interna o que torna impossível porta um código de um banco para outro sem alterações. Por exemplo a função CAST pode variar assim:
---Oracle - CAST -> ( [ Expression | NULL | ? ] AS Datatype)
---MS SQL Server -> CAST ( expression AS data_type [ ( length ) ] ) ou CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
---PostgreSQL -> CAST ( expressão AS tipo ) AS apelido
---MySQL -> CONVERT(expr USING transcoding_name) ou CAST(character_string AS character_data_type CHARACTER SET charset_name)
Então apesar da DML (Data Manipulation Language - Linguagem de manipulação de dados) ser padrão existem várias diferenças em algumas funções. O que torna a mudança de banco de dados trabalhosa.
Ao deixar as regras de negócio e manipulação dos dados na aplicação fica mais simples desenvolver uma aplicação independente do banco de dados, desde que projetada para isto.
Se a aplicação usar padrões de projeto as regras de negócio ficam separadas facilitando a leitura e a manutenção.
No caso do exemplo acima, se for efetuada qualquer alteração na função você deve alterar o banco de dados e a aplicação e atualizar. E se você tem vários clientes pode ser trabalhoso. Se a regra estiver na aplicação, basta alterar e ficaria mais simples replicar para os clientes.
Quando você usa o tratamento dos dados no banco de dados a lógica fica encapsulada e o desenvolvedor tem de abrir o banco de dados e procurar onde este sendo feito o tratamento, se fica na aplicação é só ir na onde estão as regras de negócio o que facilita.
Agora se você enquanto analista responsável achar que a melhor solução e fazer tudo no banco de dados então faça, basta justificar tecnicamente com equipe do projeto. Afinal ninguém conhece mais do seu sistema/projeto do que quem esta projetando/desenvolvendo.
20/03/2015
Mariana Carvalho
Obrigada.
22/05/2015
Gabriel Queiroz
22/05/2015
Thiago Santana
22/05/2015
Mariana Carvalho
Me explique o é o data annotation, por favor.
22/05/2015
Mariana Carvalho
A linguagem responsavel? Esse processo no banco o tornaria mais lento não é, um trabalho extra para ele.
22/05/2015
Jothaz
A linguagem responsavel? Esse processo no banco o tornaria mais lento não é, um trabalho extra para ele.
A questão não trabalho, pois o este esforço para o BD é minimo.
Seria questão de melhores práticas.
Ao colocar este tipo de operação no código você ganha em:
1-Legibilidade - fica mais fácil e simples acessar o conteúdo do método usado para consistir, não seria necessário acessar o BD.
2-Atomicidade - sua aplicação não fica dividida, toda a lógica fica nela.
3-Migração - ao usar funções nativas de um determinado BD para construir sua lógica pode ser que em outro BD esta funçãoes não sejam as mesmas. Isto dificulta a migração para outro BD e hoje é impoortante que as aplicações funcionem em qualquer bacno de dados.
Annotations são um forma que por exemplo o .Net MVC 5 permite adicionar consistências e validações na propria classe.
public string Title { get; set; }
[Required(ErrorMessage = "Price is required")]
[Range(0.01, 100.00,
ErrorMessage = "Price must be between 0.01 and 100.00")22/05/2015
Mariana Carvalho
Clique aqui para fazer login e interagir na Comunidade :)
