(Resolvido) Campos vazios em um registro consomem espaço?

[Renan Hagiwara]

Bom galera a dúvida é a seguinte: Eu tenho uma tabela com 30campos por exemplo, eu adiciono um registro nessa tabela que preencheu somente 10campos dos 30, os 20 restantes que ficaram sem valor (null) ocuparão espaço no banco ou dependendo a quantidade de registros nessa tabela futuramente tornará as consultas um tanto demoradas?

obrigado.

[Mestre SAM]

dae renan,

cara, ocupar sempre vai ocupar.

imagina criar um documento do word vazio, sem escrever nada dentro.

ocupa espaço no hd?

então, mesmo sendo null, o banco precisa saber q é null,

e pra saber q é null, ele precisa armazenar essa informacao em algum local.

e essa informacao armazenada ocupada espaço.

claro q não é pesado e ponto de deixar seu sistema lento.

a ponto de deixar futuramente lento, isso vai depender de como você vai usar tb.

se forem campos do tipo blob, ou se você fizer consultas em campos textos usando like,

ou em campos sem indexacao, ou com joins entre tabelas sem chave estrangeira.

essas coisas.

mas pode criar suas colunas null, não tem problema não. isso é comum.

sucesso ai.

[Renan Hagiwara]

Mestre SAM, obrigado pelas respostas, eu entendi bem com a sua explicação! ;]

Veja só, os campos da tabela serão CHAR(1), é uma tabela de opcionais que serão marcado com 1 caso aquele produto tenha o opcional, porém nem todo opcional se aplica a todo produto né, então terão produtos que terá alguns poucos opcionais de todos os disponíveis deixando o resto vazio (null).

Futuramente se a tabela chegar a ter vamos supor 20mil registros, você acha que não terá problemas de lentidão, demora nas consultas e tal?

Obrigado novamente Mestre SAM, abraço!

Editado Dezembro 3, 2008 por Renan Hagiwara

[Denis Courcy]

Oi, 'Renan Hagiwara'

Veja só, os campos da tabela serão CHAR(1), é uma tabela de opcionais que serão marcado com 1 caso aquele produto tenha o opcional, porém nem todo opcional se aplica a todo produto né, então terão produtos que terá alguns poucos opcionais de todos os disponíveis deixando o resto vazio (null).

Em resposta a esta primeira dúvida, comento:

Campos Char uam o espaço que foi destinado a eles mesmo se estiverem com nulo. Assim, um campo char(10) sempre terá 10 bytes de ocupação.

Os campos Varchar usam 1 byte a mais de ocupação. Então, para varchar(4), por exemplo, se contiver nulo ocupa 1 byte na tabela e se contiver (4 bytes, como nesta string, por exemplo "aaaa") ocupará 5 bytes na tabela(Ver seção 6.2.3.1. Os Tipos CHAR e VARCHAR, no manual do mysql (versão 4.1 tradução em português).

Os campos Text e Blob usam 2 bytes a mais de ocupação. (Ver seção 6.2.6. Exigências de Armazenamento dos Tipos de Coluna, no manual do mysql (versão 4.1 tradução em português).

Se suas tabelas tem muita alteração então é aconselhável evitar o uso de colunas VARCHAR ou BLOB. (Ver seção 5.2.13. Mais Dicas sobre Otimizações no manual do mysql (versão 4.1 tradução em português).

Se você ainda assim, utilizar este tipo de campo em tabelas que sofrem muita atiualização, você poderá otimizar (desfragmentar) as tabelas usando o comando OPTIMIZE TABLE. Ver Seção 4.6.1. Sintaxe de OPTIMIZE TABLE no manual do mysql (versão 4.1 tradução em português)

Quanto a segunda dúvida

Futuramente se a tabela chegar a ter vamos supor 20mil registros, você acha que não terá problemas de lentidão, demora nas consultas e tal?

Tenho clientes cujos bancos possuem tabelas com mais de 600.000 registros e não há problemas de lentidão. Basta fazer como o Mestre SAM falou neste trecho:

...se você fizer consultas em campos textos usando like,

ou em campos sem indexacao, ou com joins entre tabelas sem chave estrangeira.

essas coisas.

.

Ao Mestre SAM:

Você disse:

...se forem campos do tipo blob...

Tabelas com campo do tipo blob não ficam lentas. A chave está sempre na otimização e o uso correto de índices.

[Renan Hagiwara]

Denis Courcy, obrigado pela resposta.

Então o melhor tipo para os campos da tabela de opcionais seria CHAR(1) mesmo né? Pois eu preencho com 1 caso o produto tenha o opcional e 0 caso não tenha, já que, este opcional é uma coisa que não mudará constantemente, somente se o usuário cometer um erro na hora de cadastrar o produto e quiser alterar depois mais isso é mínimo.

Resumindo o problema: Eu estou planejando fazer um sistema que seja possivel anunciar dois produtos de nome igual, porém com opcionais diferentes, ou seja, Produto1 é igual Produto2 no nome (inclusive estarão armazenados na mesma tabela), mas tem características diferentes entre si. Eu criando uma tabela Opcionais com todas os opcionais possíveis para os dois produtos em forma de campos do tipo CHAR(1) para valor "1" caso tenha o opcional e "0" caso não tenha. Vocês modelariam desta forma como estou pensando ou utilizariam outra maneira?

Obrigado. Até mais!

[Denis Courcy]

Oi, 'Renan Hagiwara'

Neste caso eu modelaria de forma diferente.

Eu não cadastraria o que você chamou de produto 2. Cadastraria apenas o produto 1. Criaria uma tabela de domínio e chamaria de "opcionais". criaria uma tabela de relacionamento (que seria o relacionamento de muitos para muitos entre as tabelas produto e opcionais) e a chamaria de "modelo".

Nesta tabela de modelo eu guardaria o código do produto e o código do opcional além de outros campos se fosse o caso.

Esta seria a forma correta para a modelagem deste negócio. (atende a 3a forma normal).

[Renan Hagiwara]

Obrigado Denis Courcy e Mestre SAM pela ajuda, vou trabalhar um pouco mais aqui no sisteminha e qualquer dúvida volto a postar hehehe!

Abraço, té mais!