Quando os romanos queriam escrever o valor de mil oitocentos e trinta e seis, eles escreviam MDCCCXXXVI. Vinte e oito, escreviam XXVIII. Cinquenta e quatro, LIV.
Bom, a verdade que você pode mostrar o número dez como "10", "dez", "★★★★★★★★★★" (10 estrelas), "1010" (número binário), "A" (hexadecimal), enfim, o mundo é lotado de códigos diferentes para uma única informação. O uso que você irá fazer daquela informação é o que irá determinar qual código deverá usar.
Não há nada de errado, por exemplo, com o código romano para dizer os números "98" ou "14". Isso até o momento que você tiver que dividir 98 por 14. Daí percebemos que o código que os árabes inventaram para expressar números funcionam muito melhor para operações aritméticas.
Bom, mas o que isso tem haver com banco de dados? TUDO!
Aqui mesmo no blog também já há outro artigo sobre este assunto e que recomendo sua leitura: Entendendo os tipos de dados do LibreOffice Base. O artigo pode ser acessado AQUI. Não deixe de ler!
Quando você configura uma tabela de banco de dados, uma das coisas que você precisa especificar para cada campo é seu tipo . Quando você define um tipo para um determinado campo, o banco de dados passará a "usar um código específico" para interpretar os dados armazenados naquele campo.
Podemos, por exemplo, usar números num registro. Mas não necessariamente isso irá significar que tais números servem cálculos aritméticos. Um exemplo é um número de telefone. Ele nunca será somado ou subtraído com nada. Portanto, é preciso saber que tipo de dado é o mais adequado para armazenar este número. Em suma, existe uma regrinha básica para seleção de tipos numéricos. A pergunta a ser feita é: os números serão usados para qual finalidade?
Números de uma maneira geral representam quantidades. O CPF ou CNPJ são quantidades? Não. Trata-se de identificadores. A semântica correta para este tipo de dado no LibreOffice Base é o text(varchar). Afinal trata-se de uma informação descritiva.
A possibilidade de haver zeros à esquerda, por si só, já se constitui num excelente motivo para o uso do text(varchar). Portanto, você sempre deverá optar por text(varchar) em qualquer dado, até que encontre um motivo muito bom para escolher outro tipo. Um ID, por exemplo, tem um bom motivo para ser do tipo "Integer", já que trata-se de um valor que talvez seja incrementado, somado +1 a cada registro. Portanto haverá um cálculo com ele. O mesmo vale para salário, preço, quantidade... tudo são dados que podem fazer parte de uma conta. Portanto, estamos falando de tipos numéricos.
Porém o mesmo raciocínio não vale para CEP, telefone e nem mesmo o número do imóvel. Já uma data de nascimento possui todos os motivos para ser de tipo "Date", pois trata-se de um valor que você pode precisar classificar tal informação numa sequência de dias, meses e anos. Se fosse texto isto não funcionaria. Daí a importância de se usar o tipo correto.
No caso do CPF e CNPJ, há quem afirme sobre a necessidade de usar um campo do tipo texto, devido a característica dessas informações possuírem pontuação, além de números. Porém este não é um argumento válido, já que pontuação não deveria ser gravada num banco de dados. Pontos e traços são elementos que deveriam ser administrados somente na apresentação do valor, já que a pontuação não faz parte do dado.
Aliás há casos em que o tipo numérico, nem querendo possui condições de ser usado, já que a quantidade de dígitos necessários para identificar algo é maior do que o tipo numérico é capaz de comportar.
Infelizmente a maioria das falhas e interpretações equivocadas sobre esse assunto, são derivados de informações erradas em fóruns e redes sociais na internet.
Problemas com nomes de tabelas
Existem vários outros problemas em bancos de dados que não são necessariamente derivados de tipos incorretos de dados. Um desses problemas mais comuns são casos de tabelas cujos nomes não possuem um significado. Trata-se de tabelas com nomes indecifráveis ou sem sentido como "TabelaX", "Teste", "tabela01", "Lista", etc. Suas colunas seguem com os mesmos problemas de semântica e na grande maioria, não possuem sequer os comentários de campos preenchidos, tornando um enigma para qualquer pessoa.
É claro que a padronização de campos e nomes de tabelas não é uma obrigatoriedade para que uma base de dados funcione adequadamente. Campos e nomes padronizados também não são o que irá tornar os dados confiáveis. Entretanto o uso de uma padronização é o que mostra o nível de maturidade de um profissional responsável pela administração ou criação das estruturas de dados.
A intenção deste artigo não é criar um manual de padrões ou determinar normas para construção de bases de dados. Mas o foco é melhorar a qualidade das estruturas de dados de uma maneira simples e eficiente.
É possível criar inúmeros modelos de padronização, sendo assim, não existe o conceito de certo ou errado. Entretanto o conceito comum é que se tome cuidado com os exageros ou falta de critérios lógicos.
Regras básicas
Antes de tudo, você deve sempre respeitar as características e limitações do seu SGBD. O Oracle, por exemplo, não aceita mais do que 30 caracteres para nomear um objeto. Mas imagine! Temos que concordar que querer ultrapassar essa limitação para nomear um objeto já é um enorme exagero.Veja abaixo algumas características e limitações encontradas nos principais SGBDs para nomes de tabelas, colunas e outros objetos e que, portanto, o uso deve ser evitado ao máximo:
1. Não usar espaço em branco;
2. Não usar hífen, acentos e caracteres especiais;
3. Não usar palavras reservadas como: INSERT, DELETE, SELECT, NAME, etc.;
4. Não usar mais que 30(trinta) caracteres;
Além dessas limitações, seguem abaixo algumas sugestões para nomes de tabelas, colunas e outros objetos e que podem ajudar a manter o banco de dados mais "decente":
1. Não usar verbos;
2. Escrever em maiúsculo ou minúsculo;
3. Não utilizar palavras no plural;
4. Não usar preposições;
4. Não usar números;
5. Não usar nomes próprios;
6. Separar palavras com underline ao invés de hífem;
7. Crie nomes sucintos e objetivos;
8. Os nomes de tabelas e colunas não podem ter várias interpretações. Por exemplo, "Cadastro". Muito bem, mas "cadastro" do que?
Quer saber mais? Não deixe de visitar a playlist sobre o LibreOffice Base em nosso canal no Youtube. Acesse aqui. Espero que este artigo seja útil. Até a próxima!
Participe deixando seu comentário, dúvida, sugestão, ideias, críticas, exemplos ou o que você quiser na parte de comentários desta postagem. Sua participação é extremamente importante para que este blog esteja sempre melhorando o seu conteúdo.
Assine nossa newsletter!
Informe seu e-mail e clique em Assinar.