Arquivo de maio \16\UTC 2010

Varchar ou Char?

Quando as pessoas criam as tabelas num banco de dados, parece unânime a escolha de ‘varchar’ para representar strings e texto curto em geral. Em pouquíssimos lugares vê-se o uso de ‘char’.

Para coisas maiores, acabam usando algo como ‘text’ ou ‘longtext’ (nomenclatura do MySQL, pode variar), que permite, em geral, até 64KB e até 2GB de texto, respectivamente.

– Por que isso é feito assim?

O varchar é um tipo existente em, possivelmente, todo banco de dados, e guarda apenas a quantidade de caracteres do texto armazenado, sem adicionar espaços em branco. Por exemplo, se temos um campo varchar(40), ele vai armazenar fisicamente de 0 a 40 bytes, dependendo do tamanho do texto inserido.

Já o tipo ‘char’, aloca espaço para todos os caracteres, deixando bytes vazios. No caso de char(40), o banco de dados vai ter exatamente 40 bytes por linha naquela coluna.

O tipo ‘text’, assim como suas variações, usa a mesma ideia do ‘varchar’, mas é feito para quantidades maiores de texto.

Veja como é o design da tabela de posts de um blog WordPress:

Veja que os tipos usados para armazenar texto são 'varchar', 'text' e 'longtext'.

Parece meio óbvio que usar um campo variável para armazenar texto é mais interessante que um campo fixo, já que poupa espaço desnecessário, no entanto, em termos de performance usar varchar pode transformar sua aplicação numa carroça.

Um banco de dados armazena seus dados em páginas de tamanho fixo, sendo que os bancos modernos usam páginas de 16KB (maioria) ou 32KB (IBM DB2). Alguns ainda usam páginas menores, como o Microsoft Access (4KB) ou o Microsoft SQL 2000 (8KB).

Desta forma, quando você adiciona uma linha numa tabela de um Banco, ele vai procurar a próxima página que tenha espaço suficiente e vai escrever seus dados lá.

Abaixo temos um exemplo de uma linha sendo adicionada à uma página que estava vazia. O ponto azul é para mostrar que naquele ponto tem um ‘varchar’ que foi criado vazio.

Quando usamos um tipo de dados como ‘varchar’, a linha adicionada numa tabela pode crescer se um dia resolvermos colocar mais dados. Imagine que você está fazendo o cadastro de usuários e o campo de endereço da pessoa (varchar(200), por exemplo) foi criado sem nada escrito.

Antes que o usuário resolva adicionar seu endereço ao cadastro, outros usuários se inscreveram no sistema e, como seus dados cabiam na mesma página anterior, foram colocados juntos:

Assim, quando o primeiro usuário adiciona seu endereço ao cadastro, a página onde os dados dele estavam já não tem mais espaço.

A solução que o banco dá é de colocar o novo dado no lugar certo e empurrar o excedente para a próxima página que tenha espaço livre. Além disso, ele cria um ponteiro da primeira página para a segunda, mostrando que, sempre que for preciso ler os dados do último usuário, ele tenha que acessar duas páginas:

– Qual o problema disso?

Para entender o porquê disso ser algo ruim é preciso saber que o banco de dados, por mais que armazene tudo em disco, ele precisa fazer o mínimo possível de acessos ao disco, para manter uma performance boa.

Tempos de acesso em Processador 32-bit rodando à 2.0GHz

Pela tabela acima, vemos que o tempo que o processador precisa esperar para que um dado do HD chegue à ele é mais de 140.000 vezes maior que pegar um dado da memória. Assim, usando uma página de 32KB e lendo em blocos de 512B (No final de 2009, HDs de blocos de 2KB começaram a ser padrão), o tempo gasto para fazer essa leitura pode ser muito grande, ainda mais se as duas páginas não estiverem fisicamente próximas.

– Então, vale a pena economizar espaço e depois ficar com um banco lento?

Algumas vezes esse problema não vai ser percebido, talvez pela aplicação não ser grande o suficiente ou talvez por não haver atualização nos dados.

Se for sabido de antemão que não haverá mudança numa linha após a sua criação, então não há problema algum em usar Varchar.

– Mas vale a pena correr o risco?

Vamos ver: Digamos que eu tenha uma tabela com 10 campos do tipo varchar(40) e a previsão é de que essa tabela receba até 10 milhões de linhas.

Dependendo dos dados, o tamanho da minha tabela pode variar de 10MB até 410MB, já que o Varchar armazena 1 byte para sinalizar o tamanho utilizado, que é menor ou igual a 40.

Isso quer dizer que, mesmo com uma tabela ENORME, eu só vou economizar uns 100 ou 200MB de espaço em disco!

Quanto custa um terabyte hoje? 2000 Reais? 1000 Reais?
Não, 200 Reais ou menos.

Por outro lado, se o seu texto for grande (> 255B) ou tiver uma grande variação de tamanho (desde 1 ou 2KB até 100 ou 200KB), é interessante utilizar um campo variável, como é o ‘text’ e o ‘longtext’ do MySQL.

Monitores atuais

Ultimamente eu tenho notado que os monitores de LCD estão crescendo e as resoluções diminuindo.

Na época em que os CRT’s ainda eram populares, as pessoas tinham ou monitores de 17″ de resolução 1280×1024 ou tinham aqueles de 14/15″ de 1024×768. O primeiro com formato 5:4 ‘quadradão’ e os outros com 4:3 (um pouco menos ‘quadradão’). Era raro ver qualquer coisa diferente disso.

As primeiras telas finas a ficarem populares foram as de plasma, mas, por conta da dificuldade de fazer pixels pequenos, elas eram comumente de baixa resolução 854×480 – algo que temos em LCDs de celular – e eram enormes (40″, 50″ ou maior). Seu formato é 16:9, que é bem mais esticado que o 4:3.

Em comparação com as TVs CRT de 500 linhas verticais, essas telas de plasma são até boas, mas para usar com um computador não dá muito certo.

Logo após, começaram a surgir monitores de LCD com o formato dos CRTs. Aqueles da Samsung e LG, entre outras, de 17″ e resolução 1280×1024 são ainda bem comuns, mas praticamente não são mais fabricados.

Talvez por causa dos notebooks serem bem mais compridos que largos, painéis de LCD começaram a ficar alongados.

A primeira safra foram dos monitores 15,6″ de resolução 1280×800 (16:10), que tem exatamente a mesma largura do monitor 5:4 de 17″, mas com menos pixels verticais. Para notebooks esse monitores aprecem em tamanhos de 15,6″, 14″ e 13,3″, normalmente.

Praticamente junto da resolução 1280×800, surgiram os monitores de 17″ 1440×900 e um pouco depois os 1680×1050, ambos também 16:10. Essas versões foram destinadas basicamente à monitores de Desktop.

Durante esse tempo, as TVs de Plasma já começaram a apresentar resoluções maiores e passaram a competir com os LCDs que estavam barateando. Apareceu no mercado mais um padrão de resolução que era o 1366×768, um formato 16:9, o mesmo usado no cinema. Ele é um pouco maior que o 720p, que é 1280×720, que também começou a ficar famoso. Ambos são considerados HD (High Definition).

Nas TVs, ainda, surgiu o Full HD (ainda maior que o HD) também conhecido como 1080p e é um formato 16:9 de resolução 1920×1080. Nos monitores surgiu o 1920×1200, que é 16:10 (Normalmente para telas de 22″ e 24″).

Para assistir filmes, nada melhor que ter a tela inteira preenchida com a imagem, sem aquelas barras pretas em cima e embaixo. Já no uso do computador, qualquer quantidade de pixels verticais já ajuda, por causa das barras de programas, título das janelas, barra de abas, barra de ferramentas, etc.


Firefox no Windows 7 em resolução 1280×720. Apenas 540 pixels verticais estão disponíveis para o conteúdo.

Claro que, usando uma tela Full HD, mesmo sendo 16:9, o problema desaparece, mas veja que 1080px verticais são quase os mesmos 1024px dos monitores CRT de 17″.

Mesmo assim, por causa desse apelo do formato de cinema, a nova safra de monitores parece estar seguindo essa tendência. Olhando em sites de compras, praticamente só se vê monitores de 18,5″ (18 é o novo 17) com 1366×768, monitores de 19″ com 1600×900 e monitores de 21,5″ com 1920×1080 de resolução. Todas no formato 16:9.

Para monitores de notebook menores, também começaram a aparecer resoluções como 1280×720 e 1024×576, ambas 16:9, como se alguém comprasse um aparelho com tela de 10″ para assitir filmes.

Mudando de 1024×600 (16:10) para 1024×576 num netbook, você perde 24 pixels, que é exatamente o tamanho de uma barra como a de programas do Windows!

Veja abaixo uma comparação de monitores comuns:

Abaixo uma lista ordenando as resoluções pelo total de megapixels:

É interessante ver como um monitor de CRT antigo de 17″ tem mais pixels que os monitores de 17″ e 18,5″ vendidos atualmente. A diferença é quase inexistente para os monitores de 17″ 1440×900, mas para os de 18,5″ atuais de 1366×768, temos uma grande perda de pixels e mais ainda de espaço vertical.

É claro que existem exceções, mas os monitores estão ficando maiores e as resoluções menores, tudo isso para adaptar as telas ao formato de cinema.

Minha opinião:
Telas alongadas são mais agradáveis, pois nossos olhos estão na horizontal e conseguem captar mais informação sem ter que subir e descer a cabeça. Ao mesmo tempo, temos que conseguir conciliar o problema do espaço vertical disponível.

Para televisão: Não há dúvidas que o formato 16:9 é a melhor opção, desde que os programas exibidos também sejam nesse formato. Eu vejo muita gente com TV Full HD assistindo rede Globo com a imagem 4:3 esticada num telão de 50″ em 16:9.
Para computador: Depende. Entre um monitor 16:10 e um 16:9, primeiro eu escolheria pelo número de pixels e depois pelo formato.