[firebase-br] Espaco: CHAR x VARCHAR

[Josué]

Eu sei que tecnicamente ou na área acadêmica tudo indica o contrário, 
inclusive alguns livros indicam o tipo CHAR somente para campos lógicos. Por 
isso frisei ser opinião e não recomendação.
Fiz analogia com os clusters, porque é hoje a grande preocupação de espaço, 
já que os discos estão aumentando consideravelmente de tamanho em velocidade 
muito maior que o enderessamento.

Quis chamar a atenção de onde surgiu a necessidade de criar campos 
variáveis, que foi as deficiências de hardware na era jurássica. E olha que 
achei companheiros que sofreram as mesmas agrurias (sem saudades).

Não conheço o sistema de armazenamento físico do Firebird, por isso não 
mencionei, mas se for como o amigo mencionou, fica evidente o aproveitamento 
de espaço e aí sim o campo VARCHAR ganha importância.
Inclusive neste caso o tamanho do cluster é irrelevante.Inclusive, qto 
maior, mais rápida a leitura do arquivo.Ponto para o Firebird!

A preferencia pelo CHAR é pessoal e pelas "manias" de programar. Mas vejo 
que em SQL as coisas são diferentes. Devagar eu aprendo.

Abraços.

Josué D. Silva
Telecomunicações Curupira Ltda
SCM - Ouroeste - SP
017 - 38431606
----- Original Message ----- 
From: "Douglas Tosi" <douglasht em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, July 03, 2009 4:49 PM
Subject: Re: [firebase-br] Espaco: CHAR x VARCHAR


2009/7/3 Josué <josue em ciberpoint.com.br>:
> Eu acredito que na tecnologia dos HDs atuais, é mais preocupante o
> gerenciamento dos clusters, pode ser que se perca mais espaço com clusters
> subutilizados do que a economia dos VARCHAR.

Josué, a discussão char x varchar não tem nada a ver com má utilização
de cluster do disco.

Sabemos que *arquivos* diferentes não podem compartilhar o mesmo cluster.
Mas a base de dados fica inteira em um (ou poucos mais) arquivos bem
grandes. Não existe subutilização de cluster.
Você pode mudar um pouco o foco desta análise e pensar em
subutilização de páginas da base. Aí sim. Elas são o equivalente em
alto nível dos clusters. Mesmo assim acho que não tem relação com a
discussão char x varchar.

O varchar precisa guardar o tamanho real e por isto vai sempre ocupar
2 bytes a mais *no disco*, mas o char sempre vai trafegar o tamanho
inteiro *na rede* e *na memória*.
Daí é que vem o senso comum de que char é usado para campos com
tamanho fixo: Se você já sabe o tamanho de antemão, pode muito bem
economizar 2 bytes usando char. Mas se você não sabe o tamanho de
antemão, usar char para economizar 2 bytes não faz sentido. Em um
milhão de registros, vai economizar ~1,8MB. Coloque isto na balança
contra o trabalho que dá manter e programar *ao redor* de campos char
cheios de espaço no fim.

Na minha [nada] humilde opinião, usar campos Nome CHAR(60) é
improdutivo e um contracenso.

hth,
-- 
Douglas Tosi
www.sinatica.com

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa