Home
All Posts
All Tags
Informação representada por números vs Tipos Numéricos

É pa lê ou pa conta?

Bom, hoje eu quero falar de um assunto que sempre aparece quando estamos falando sobre modelagem de dados, seja banco de dados, seja classe, seja o que for, sempre que aparece um campo do tipo CPF, DDD, TELEFONE… até mesmo o famoso ID, sempre bate aquela dúvida, de que tipo será este campo? Int? Decimal? String? Guid? NDA?.

Confesso que já sofri bastante com modelagem ruim, quem nunca pegou um campo DDD do tipo int e depois teve que formatar o dado com o 0 a esquerda? Pois é, no meu ponto de vista as pessoas modelam os dados de forma incorreta, visando “facilitar” o trabalho de colocar informações neste local, deixando coisas como validação à cargo do tipo ao invés de desenvolverem estas regras.

Geralmente quando estou modelando dados, sempre que uma informação aparenta ser numérica eu tento entender ao máximo qual será o propósito daquela informação antes de sair definindo seu tipo, em diversas conversas com amigos que trabalham na área, acabei desenvolvendo uma pequena técnica simples para definir qual seria o melhor tipo para uma determinada informação nesta situação, a fórmula é a seguinte:

Essa informação será utilizada em operações matemáticas?

SIM: Então utilize um tipo numérico como INT, DECIMAL, FLOAT, LONG, etc.

NÃO: Então NÃO utilize um tipo numérico, use algo como String, Guid, Varchar, Char, Date, DateTime, TimeStamp e por ai vai.

Esse tipo de problema acontece muitas vezes no ID, onde as pessoas acabam escolhendo ser do tipo Inteiro buscando facilitar o incremento das entidades através de mecânicas já implementadas, por exmeplo do lado de um danco de dados, vale ressaltar aqui que esta é uma técnica válida, tanto que existe e muita gente utiliza, o ponto que precisamos manter a atenção é que, se você por um acaso após inserir um item no seu banco de dados, imediatamente precisa saber o ID dele, provavelmente seria muito melhor você controlar o ID dos seus elementos e não o seu banco de dados. Além disso, já que agora você vai controlar os IDs dos seus elementos, qual seria a necessidade dele ser um número ou uma sequência?

Para saber a ordem em que eles foram colocados no banco de dados?

R: Use outro tipo de informação, um campo de data seria o mais adequado.

Para saber qual seria o próximo ID da sequência de elementos?

R: Ao menos que o próximo elemento tenha alguma ligação com o elemento anterior, isso não faz a menor diferença, se o elemento 1 não tem conexão com o elemento 2, eles poderíam deixar de ser 1 e 2 para ser ABC e XPTO.

Mas como vou saber o último ID que adicionei? Como pegar o Max Value?

R: Outra vez você está partindo para o lado errado, qual sentido faz você saber o último valor inserido? Somar +1 para gravar o próximo? Para voltar ao caso anterior e ter os elementos 1 e 2? Tente encontrar em seu elemento dados que o tornem único, algo como um documento, um e-mail, uma chave, talvez você precise de mais do que apenas uma informação deste elemento e só vai conseguir utilizando dois ou mais campos.

O fato é, você não deve utilizar um campo numérico apenas para evitar que letras sejam armazenadas neste local, para mim isso está errado, quer um exemplo? Vamos fazer um pequeno cadastro de endereço, bem simples, Rua, Número, Bairro, Cidade, CEP, abaixo vamos definir os tipos.

Campo Tipo
Rua String
Número Integer
Bairro String
Cidade String
CEP Integer

Olha que bacana, consegue ver o tamanho do problema que você acabou de criar?

Este modelo acima não conseguirá aceitar informações do tipo Rua Dos Bobos, 23A, seu campo Número é do tipo Integer e não vai aceitar a letra A, outro ponto é que você não vai trabalhar este número matematicamente, por exemplo você nunca somará o número das casas com outros números, este é um forte indício para que esse campo não seja do tipo Inteiro, seguindo este exemplo talvez fosse melhor ele ser do tipo String.

E o campo CEP? Esse é pior ainda!

O campo CEP é mais um campo completamente descrito por números, que nunca serão somados com outros, pode ter zeros a esquerda e ainda possui uma formatação específica(00000-000), esse hífen no meio do CEP faz parte de sua informação e deve ser considerado.

Tá certo, então O CEP deveria ser String também?

Não sei, precisamos entender melhor como vamos utilizar este campo de CEP.

Supondo que ele seja um campo informativo onde queremos apenas ter o cadastro do CEP de nossos clientes, ele pode ser String e você poderia validar a informação deste campo utilizando por exemplo uma Expressão Regular(regex).

Agora supondo que temos um sistema de cálculo de Frete, onde será importante identificar se um CEP está dentro de uma faixa de CEPs, talvez fosse melhor modelar este campo de forma separada e já que vamos ter que calcular faixas com este número, talvez fosse realmente o caso de utilizar tipos númericos para cada parte.

Resumindo, não será o tipo do campo que vai resolver o problema, ele só faz parte desse problema e você precisa estar atento ao todo para tomar a melhor decisão.

Bom, acho que consegui explicar a ideia.

Ficou com alguma dúvida? Tem alguma sugestão, quer conversar sobre o assunto ou sobre qualquer coisa relacionada? Então é só entrar em contato comigo através das redes sociais que estão logo ali na parte de cima do blog.

Forte Abraço, valeu!

CSS3 - Centralizando conteúdo verticalmente com flex-box

display:table-cell+vertical-align: middle

Se você nunca precisou alinhar um conteúdo ao centro no eixo vertical de um div, fique tranquilo, seu dia chegará e você lembrará desta dica, mas antes da solução, vamos entender o que acontece.

Muuuuuuuuuuuuito antigamente os sites eram todos diagramados utilizando as famosas tabelas e suas células, porém quando as pessoas entenderam que este não era o melhor modo para se diagramar um site e que principalmente existiam elementos específicos para este tipo de trabalho, o mundo da diagramação de sites foi revolucionado dando espaço ao o que conhecemos como tableless, neste novo modelo tabelas deveríam ser utilizadas apenas para exibição de dados tabulares. Incrível, não?

Com a chegada do tableless substituindo tudo o que era table, tr, th e td por div, span, ul, li, p, os problemas logo começaram a aparecer, um dos melhores exemplos é que naturalmente um div não fica alinhado ao lado do outro, o valor padrão da propriedade display de um div é block, o que faz com que todo div estique sua largura até 100% respeitando a largura do objeto relativo(do que ele está dentro). Mas este não foi o pior problema que apareceu, o maior vilão mesmo sempre foi o famoso vertical-align que funcionava perfeitamente quando aplicado em uma célula e agora não funcionava em um div.

Recentemente(já tem um certo tempo), ganhamos um grande aliado chamado flex-box, um novo valor que pode ser utilizado para configurar a propriedade display dos nossos maravilhosos divs. Quando display está definido com o valor flex em um div, ganhamos diversas outras propriedades que nos ajudam no controle do alinhamento dos elementos internos do div em questão.

É exatamente ai que nossos divs começam a ter o poder de alinhar objetos internos da mesma forma que a propriedade vertical-align alinhava os objetos internod de uma célula. Porém, muita calma nessa hora, não espere encontrar uma nova propriedade chamada vertical-align, pois esta propriedade ainda existe e ainda não funciona, você deverá utilizar as novas propriedades relacionadas ao display: flex chamadas align-items e justify-content, essas duas belezinhas vão resolver nossos problemas de alinhamento de forma bem simples, veja o exemplo abaixo:

<style>
  .div1 {
    height: 100px;
    width: 100px;
    border: 1px solid #000;
    display: flex;
    align-items: center;
    justify-content: center;
  }
  .div2 {
    height: 30px;
    width: 30px;
    background-color: #87D37C;
  }
</style>
<div class="div1">
  <div class="div2">
    oi
  </div>
</div>

Veja abaixo como é exibido o exemplo descrito acima:

oi

Como podemos ver, o elemento div2 está centralizado verticalmente e horizontalmente através das propriedades align-items e justify-content, onde ambas foram configuradas com o valor center para o div1. Simples, né?

Esta foi só uma das dicas envolvendo flex-box, se você se interessou pelo assunto e quer mais informação a respeito, recomendo este excelente guia em inglês onde você encontrará em detalhes o funcionamento do flex-box para que você entenda tin-tin por tin-tin o que, como e onde as coisas acontecem.

Espero ter ajudado e que agora você consiga posicionar seus itens verticalmente centralizados sem gambiarras(transform: translate(-50%,-50%)).

Abraço!

Fortalecendo a comunidade brasileira de desenvolvimento

Um blog em português para nós

#IniciandoOsTrabalhos deste blog (espero que também não seja o fim) com a ideia de contribuir de alguma forma com a comunidade brasileira de desenvolvimento. Sempre gostei de compartilhar conhecimento, me sinto bem ao perceber que consigo colaborar com as pessoas de forma positiva, acredito que este canal venha me fazer bem ao mesmo tempo que fará bem para os outros.

A ideia principal deste canal é documentar estudos e compartilhar conhecimento da melhor forma possível, seja de assuntos que eu domine ou de assuntos que vamos aprender juntos.

“Mas Thiago, você vai escrever o blog inteiro em português?”

Sim. Provavelmente você verá alguns termos em inglês(imagem do post da publicação, imagem do header cabeçalho), mas a maior parte do conteúdo será disponibilizada em português.

“Em inglês não daria mais visibilidade?”

Provavelmente, mas é exatamente este o ponto, o foco não é visibilidade, o blog será uma forma de me ajudar a estudar e aprimorar minhas técnicas de compartilhamento de conhecimento. Meu foco é ajudar o público brasileiro, inclusive eu.

“Por que o público brasileiro?”

Geralmente quando eu busco conteúdo na internet acabo encontrando diversas referências em inglês e poucas em português. Acredito que colaborando com conteúdos em português fortaleceremos mais nossa comunidade, apesar do idioma inglês ser bastante popular em nossa profissão, quero ajudar pessoas sem exigir esta skill habilidade. O mundo já está bastante recheado de conteúdos em inglês e o que estamos procurando são pessoas querendo aprender.

Assuntos que discutiremos

Como disse anteriormente, a ideia do blog é trazer conteúdo que eu tenha conhecimento e também conteúdos em que eu esteja estudando, isso inclui conteúdos mais técnicos como C#, HTML5, CSS3, JavaScript, KnockoutJs, Angular2 e por ai vai. Pretendo trazer também metodologias, padrões, dicas, testes, versionamento de código, casos reais que eu enfrente em meu dia-a-dia, basicamente o que for interessante no meu ponto de vista, porém o foco será sempre o desenvolvimento de software.

Críticas, Sugestões, Comentários e Temas

Inicialmente o blog não terá um sistema de comentários, mas você pode entrar em contato comigo através das redes sociais para que nós tclemos!!! (teclemos, teclar, tendeu? aff!!!).

Por enquanto é só, vou pensar em alguns assuntos interessantes e ver se começo a colocar conteúdo por aqui.

Abraço!