BLOB ou no BLOB, eis a questo: Armazenar dados em campos BLOB, CHAR, ou VARCHAR?

Texto Original: Ivan Prenosil Traduo: Paulo Vaz

Diferenas entre o tipos CHAR e VARCHAR Muitas pessoas acreditam que VARCHAR melhor porque armazena somente dados significativos, enquanto o CHAR armazena em todo o dado em toda sua extenso. Isto no verdade. De fato, o CHAR e VARCHAR so armazenados no buffer de memria com o tamanho declarado. Quando o registro armazenado no disco, o algortimo de compresso RLE utilizado para comprimir o registro inteiro, isto CHARs, VARCHARs, inteiros, datas, etc. todos juntos. Assim se voc quiser conservar o espao, CHARs so ligeiramente melhores do que VARCHARs ( a diferena que VARCHAR armazena o tamanho do campo em 2 bytes). H tambm um erro que faz com que o VARCHAR no limpe corretamente a string se voc atribuir um tamanho muito pequeno, assim causando uma compresso muito ruim (este problema j est corrigido a partir do Firebird-0.9.4) Muitas pessoas acreditam tambm que VARCHAR transmite apenas os dados significativos atravs da rede, enquanto o CHAR transmitido no seu tamanho total. Tambm no verdade. A comunicao entre o cliente e o servidor feita atravs de mensagens de tamanho fixo. Por esta razo o CHAR e VARCHAR so transmitidos em seu tamanho declarado (este problema reparado no Ib-6.5) Sendo assim, a deciso de usar CHAR ou VARCHAR deve ser baseada unicamente nas exigncias da aplicao. Por exemplo, armazene cdigos de tamanhos fixos no CHAR, armazene nomes em VARCHAR (para permitir a concatenao correta). Vantagens/Desvantagens dos BLOBs e VARCHARs Todos os comentrios neste pargrafo de consulta do tipo VARCHAR so vlidos para o tipo do CHAR. Cada comentrio terminado com BLOB+, VARCHAR+ ou Implementao, serve para indicar que tipo de dado melhor para situao indicada, ou ainda se uma questo de escolha ou implementao a ser feita. Voc sabe o tamanho mximo de seus dados? Com VARCHARs voc necessita declarar o tamanho mximo dos dados . Com Blobs voc no necessita preocupar-se com o tamanho dele. BLOB + Voc necessita armazenar dados em strings muito longas? Uma nica coluna de VARCHAR restringida a 32K (isto , sobre caracteres de 10Kb Unicode). O tamanho mximo do Blob varia de acordo com o tamanho da pgina de dados informado na criao do Banco de Dados e so (de acordo com a guia da operao): Pginas de 1Kb => 64 Mb Pginas de 2Kb => 512 Mb Pginas de 4Kb => 4 Gb Pginas de 8Kb => 32 Gb Pginas de 16 Kb => 256 Gb BLOB+

Voc necessita armazenar muitas campos de texto longo em uma nica tabela? O tamanho total de um registro (no compactado) restringido a 64Kb. VARCHARs so armazenados diretamente do registro, portanto voc no pode armazenar muitos strings longas em um nica registro. J os Blobs so representados apenas por sua identificao no registro, j que so gravados fora do registro, e usam entre 8 bytes e 64Kb no mximo. BLOB + Voc quer minimizar a trfego entre o cliente e o servidor? Os dados de VARCHAR so buscados junto com os outros dados de registro em uma unica operao, e geralmente diversos registros so transmitidos pela rede de uma s vez. Cada Blob necessita de um operao extra de open/fetch. VARCHAR + Voc quer minimizar a quantidade de dados transferidos entre o cliente e o servidor? Com Blobs voc tem a vantagem que aps ter recuperado o registro voc pode decidir se que ou no buscar dados do tipo Blob ligados ele. Com VARCHAR voc tem a desvantagem, que estes so transmitidos atravs da rede no tamanho declarado (VARCHAR's muito longos degradam o desempenho de forma significativa em redes locais, para no mencionar conexes via dial-up.) Este problema reparado em Ib-6.5, que transmite somente dados significativos de campos VARCHAR. BLOB +(VARCHAR + para IB 6.5) Voc quer minimizar o espao usado? VARCHARs so compactados com RLE (de fato o registro inteiro comprimido, exceto os Blobs). Na maioria das vezes 128 bytes podem ser comprimidos a 2 bytes. Isto significa que um VARCHAR (32000) vazio, ocupar 500+2 bytes. Os Blobs no so compactados, mas se vazios (isto quando esto NULL) ocuparo somente 8 bytes no registro para sua identificao (e isto ainda poder ser compactado via RLE). Um Blob com contedo pode ser armazenado na mesma pgina que outros dados do registro ou em uma pgina de dados separada. Um Blob pequeno que cabe na pgina dos dados acrescenta aproximadamente 40 bytes (ou mais) pgina de dados. Um Blob grande tem os mesmos 40 bytes adicionais na pgina dos dados, mais 28 bytes em em cada pgina de Blob adicional ocupada (30 bytes na primeira adicional). Uma pgina de Blob no pode conter mais de um blob (isto , as pginas de Blob no so compartilhadas como pginas de dados). Por exemplo, para o tamanho da pgina 4Kb, se voc armazenar o Blob 5Kb, duas pginas do tipo Blob sero alocadas, o que significa que voc perde 3Kb do espao! Em outras palavras - quanto maior o tamanho da pgina, maior a probabilidade de que os blobs pequenos cabero na pgina dos dados, mas mais espao ser desperdiado se as pginas separadas do blob forem necessrias para Blobs grandes. VARCHAR + (exceto VARCHARs com tamanho declarado extremamente grande, ou tabelas com muitos Blobs vazios (NULL) ) Voc necessita de uma tabela com muitos registros? Cada registro identificado por uma DB_KEY (chave), que um valor de 64 bits, onde 32 bits representem a identificao de relao e 32 bits so usados para localizar oregistro. O nmero mximo de registros em teoria em uma tabela 2^32 (mas por diversas razes o mximo real sempre menor). Os identificadores do Blob (Blob_Id) so atribudos no mesmo espao de endereo que as DB_KEYs, e isto significa quanto mais Blobs na tabela, menos DB_KEYs estaro disponveis para enderear os registros da tabela. Por outro lado, quando os registros armazenados so longos (por exemplo, se contiverem VARCHAR longos), ento menos registros cabero na pgina dos dados e muitos DB_KEYs remanescero sem atribuio de qualquer maneira. VARCHAR +?

Voc quer um bom desempenho? Porque os Blobs grandes so armazenados fora das pginas dos dados, aumentam a "densidade" dos registros em pginas dos dados e o seu cache dando mais eficincia (reduzindo o nmero de operaes de I/O durante a busca). BLOB + Voc necessita executar buscas no contedo dos campos de texto? Em campos VARCHAR voc pode usar operadores como ' = ', ' > ', BETWEEN, IN(), LIKE (case sensitive), STARTING ( case sensitive) e CONTAINING ( case insensitive). Na maioria dos casos um ndice pode ser usado para acelerar a busca dos dados. Os Blobs no podem ser indexados, e voc est restrito aos operadores LIKE, STARTING, e CONTAINING. Voc no pode diretamente comparar Blobs diretamente com os operadores ' = ', ' > ' etc. (a menos que voc use uma UDF que suporte isto). Voc no pode, por exemplo, unir tabelas atravs do JOIN com campos do tipo Blob. VARCHAR + Voc quer procurar o contedo destes textos com CONTAINING ? O operador CONTAINING pode ser usado para se executar a busca case-insensitive em campos VARCHAR (no usando ndice). Visto no ser possvel definir a ordem de collation para campos do Blob, voc no pode usar inteiramente a busca case-insensitive, como no caso de caracteres nacionais em colunas do Blob (somente uma parte pequena do caracteres ser case-insensitive). Como alternativa voc pode usar uma UDF. VARCHAR + Voc precisa transformar para UPPERCASE (maiculas) os campos texto? Voc pode usar a funo interna UPPER() em VARCHAR, mas no no Blob. (tambm o CAST, MIN e MAX, que no podem ser usados em campos Blob) VARCHAR + No possvel classificar a coluna do tipo Blob (nem fazer um GROUP BY, DISTINCT, UNION ou JOIN ON). No possvel concatenar colunas do tipo Blob. VARCHAR + No h nenhuma funo interna de converso (CAST) para converter Blob em VARCHAR ou VARCHAR em Blob. (mas possvel escrever UDF para esta finalidade.) Implementao No possvel atribuir um valor Blob usando comandos SQL diretamente. Por exemplo no possivel executar um comando assim: INSERT INTO Tabela(MeuBlob) VALUES('abc '); (mas possvel usar uma UDF convertendo string para Blob). VARCHAR + O Firebird-0.9.4 tem j esta funcionalidade Implementao Tamanho do arquivo de classificao (SORT FILE) s vezes quando as quando h necessidades do interbase classificar o resultado (por exemplo para a ORDER BY, DISTINCT, ou UNION sem ALL, etc..) cria-se um arquivo temporrio. Este arquivo contem os valores de todas as registros que voc est selecionando, isto todos os VARCHARs, ou somente os identificadores dos Blobs que so mais curtos. Isto significa que campos Blob pode manter arquivos de classificao menores. BLOB + Os blobs podem ter a definio de recommended-segment-size, blob-sub_type, e usam filtros. VARCHARs no suportam tal funcionalidade. BLOB +

Existem dois tipos de campos Blobs - segmented (padro) e stream. Blobs do tipo stream no estruturado, enquanto os do tipo segmented so preservados no formato que foram inseridos no campo Blob, isto preservam os vnculos do segmento. VARCHARs no suportam tal funcionalidade. BLOB + Voc necessita de boa segurana nas campos texto? Para recuperar dados da tabela, voc necessita ter concedido o privilgio SELECT. Para recuperar um Blob, voc necessita saber somente sua identificao (armazenada na tabela), mas o Firebird no verificar se voc tem quaisquer direitos sobre a tabela com o campo Blob. Isto significa que todos que souberem ou acharem a identificao do Blob podem ler o Blob mesmo sem nenhum direito na tabela. (voc pode tentar usar o comando BLOBDUMP do ISQL.) VARCHAR + Que ferramentas voc vai usar. A deciso final (se prefirar Blob ou Varchar) pode ser determinada pelas ferramentas usadas para acessar a base de dados (componentes, middleware de Delphi...). Algumas ferramentas podem ter problemas com a manipulao Blobs, algumas outras ferramentas podem ter limitaes em VARCHARs (por exemplo limite a 255 caracteres ou a inabilidade de distinguir entre um campo vazio ou nulo). Implementao

Artigo Original: http://www.volny.cz/iprenosil/interbase/ip_ib_st rings.htm#_strings_blob_varchar Ivan Prenosil prenosil@NOSPAM.ms.anet.cz

Comunidade Firebird de Lngua Portuguesa Visite a Comunidade em: http://www.comunidade-firebird.org

Traduo e adaptao: Paulo Vaz paulo@multi-informatica.com.br

A Comunidade Firebird de Lngua Portuguesa foi autorizada pelo Autor do Original para elaborar esta traduo.