Oi! Seja bem-vindo!
Como permitir só letras ou só números no SQL Server é o assunto dessa semana, motivado pelo que aconteceu comigo durante uma reunião a alguns dias atrás.
Porque validar as informações dos campos texto
Você não vai acreditar que uma pessoa como essa ganha mais de 10 mil por mês…
Então porque validar as informações de livre digitação (quando possível, é claro)?
Estava eu em reunião com analistas de tecnologia e de produtos financeiros. Para você que não conhece a profissão “analista de produtos” eis uma definição que encontrei no site catho:
O que faz um “Analista de produtos”: Acompanha o ciclo de vida dos produtos, comportamento da concorrência e tendências de mercado, viabilidade de lançamentos, analisando resultados para identificar novas oportunidades, melhorias e modificações nos produtos existentes.
Simplificando: No caso de um banco, um analista de produtos explica a nós técnicos como os produtos financeiros funcionam, para que assim criemos os sistemas e bancos de dados para controlar, por exemplo, os investimentos que os clientes fazem.
Conheço um pouco dessa área porque em 2011 decidi estudar melhor como funciona o mercado financeiros para poder ganhar mais com meus investimentos. Já que havia estudado bastante, acabei inclusive fazendo a certificação CPA20 da ANBIMA.
Ou seja, mesmo não sendo minha área principal, entendo um pouco de investimentos porque estudei e me mantenho atualizado.
O que me chamou a atenção e motivou esse artigo, foi que durante a reunião começamos a falar sobre COEs (Certificado de Operações Estruturadas).
Na pronúncia da sigla COE, as vezes podem soar como “COI”, concorda? Já vi essa confusão acontecendo.
O que eu não havia visto acontecer ainda, era “a chefe dos analistas de produtos de um banco” fazendo anotações sobre a reunião e escrevendo “COI” na anotação…
Quando vi aquilo fiquei achando que ela devia estar muito distraída, pois como a chefe de produtos não saberia o nome de um produto?
OK se eu e você não soubermos o nome de um produto financeiro, agora o chefe de produtos financeiros?? De um banco??
Estamos falando de uma pessoa que tem sua carreira focada nisso, é como se eu (DBA) não soubesse o que é um JOIN, por exemplo!! E mais, estamos falando de uma pessoa que é a responsável pela área e que ganha um salário de mais de 10 mil reais por mês!
Para garantir que eu não estava maluco ou fazendo mal julgamento da situação, fiz uma pergunta para ela sobre COE (fazendo de conta que eu não sabia o que era…). Resultado. Ela se perdeu inteira, ficou com cara de taxo, e disse que precisaria verificar antes de responder… Foi ai que tive a certeza:
Por inacreditável que pareça, a chefe de produtos não sabia o que era um COE, um produto financeiro já no mercado desde 2013 (essa reunião foi em 2017).
Naturalmente isso rendeu conversas enormes entre eu, meus mentores, alunos, amigos, e agora você…
Mas afinal, onde eu quero chegar e o que tem isso haver com SQL?
É o seguinte, em minha humilde experiência, hoje em dia o conhecimento das pessoas está tão superficial, que nós, como desenvolvedores e DBAs, precisamos proteger cada milímetro dos sistemas e bancos de dados.
Porque digo isso? Porque se o usuário tiver qualquer espaço para fazer alguma bobagem no sistema, ele vai fazer!
Imagine um usuário (o chefe da área), que sequer conhece o nome do produto, fazendo operações para clientes dentro do seu sistema…
Nessas horas tenho a certeza de que não é por mal quando certas pessoas cometem certas trapalhadas no dia a dia as quais ficamos nos perguntando “como pode”…
É simples desconhecimento…
Poxa Josué, mas um chefe de produtos não deveria saber isso? Sim, mas ele/ela sabe? Não…
Por essas e outras, tive a ideia de compartilhar com você uma técnica para restringir o que pode ser digitado em um campo do banco…
Nossa Josué, que coisa bem específica? Sim, a história que te contei ilustra bem o motivo… rsrsrsrs
Como proteger os campos texto de nosso SQL Server?
Bem, depois dessa história toda, aposto que você também deve estar se perguntando: Josué, então como protejo meu banco? Existem várias formas, e hoje vou trazer para você uma para que você possa permitir apenas certos caracteres em um campo texto. Aqui vai o script de testes:
------------------------------------------------------------------
-- Como restringir o que pode ser digitado em um campo texto
------------------------------------------------------------------
--------------------------------------------------
-- Requisitos para nosso teste
--------------------------------------------------
-- Banco de testes
use master
if db_id('curso') is not null
drop database curso
go
create database curso
go
use curso
go
--------------------------------------------------
-- Restringindo dados inseridos
--------------------------------------------------
-- Tabela de testes
if object_id('teste') is not null drop table teste
create table teste (
so_txt varchar(100) constraint teste_so_txt check (so_txt not like '%[^a-z]%'),
so_num varchar(100) constraint teste_so_num check (so_num not like '%[^0-9]%'),
txt_ou_num varchar(100) constraint teste_txt_ou_num check (txt_ou_num not like '%[^A-Z0-9]%')
-- Dica: para incluir o "espaço" no conjunto de caracteres é só fazer assim: %[^A-Z 0-9]%
)
-- ERRO
insert into teste (so_txt) values ('1')
insert into teste (so_txt) values ('abc1def')
insert into teste (so_num) values ('a')
insert into teste (so_num) values ('123a456')
insert into teste (txt_ou_num) values ('#')
insert into teste (txt_ou_num) values ('123#abcd')
-- OK
insert into teste (so_txt) values ('abcd')
insert into teste (so_num) values ('1234567890')
insert into teste (txt_ou_num) values ('abcd1234')
-- Excluindo dados de teste
use master
drop database curso
CONCLUSÃO
Em um sistema de anotações como o Evernote, você poderia implementar essa estratégia para impedir que um usuário desavisado digitasse incorretamente o nome de um produto financeiro, concorda? Evitaria constrangimentos… kkkk
Espero que tenha gostado do artigo, nos vemos no próximo!
Abraço do seu amigo Josué