INT ou CHAR? MySQL
Tenho um atributo em minha entidade denominado nível, este atributo terá apenas um valor, ou seja: "1", "2", "3". Cada um é definido na programação como:
1 - Usuário Comum.
2 - Usuário Moderador.
3 - Usuário Administrador.
Minha dúvida é se devo usar CHAR(1) ou INT, já que o tamanho é fixo e numérico. Obrigado!
1 - Usuário Comum.
2 - Usuário Moderador.
3 - Usuário Administrador.
Minha dúvida é se devo usar CHAR(1) ou INT, já que o tamanho é fixo e numérico. Obrigado!
Jeremias Bastos
Curtidas 0
Melhor post
Joel Rodrigues
05/05/2015
Só complementando, nos casos onde você realmente precisar decidir por um tipo ou outro, e eles forem ambos compatíveis com sua informação, é interessante pensar no espaço de armazenamento. Por exemplo:
INT ocupa 4 bytes.
TINYINT ocupa 1 byte (faixa menor de valores, porém adequado ao seu objetivo).
CHAR ocupa 1 byte por posição (ou seja, char(4) ocupa 4 bytes, por exemplo).
Sendo assim, cabe avaliar: CHAR ou TINYINT? Aí vai depender da sua necessidade. Se armazenar uma letra pode ser ficar mais claro, então eu faria essa opção. Se não, então fica a gosto do cliente mesmo.
Um abraço.
INT ocupa 4 bytes.
TINYINT ocupa 1 byte (faixa menor de valores, porém adequado ao seu objetivo).
CHAR ocupa 1 byte por posição (ou seja, char(4) ocupa 4 bytes, por exemplo).
Sendo assim, cabe avaliar: CHAR ou TINYINT? Aí vai depender da sua necessidade. Se armazenar uma letra pode ser ficar mais claro, então eu faria essa opção. Se não, então fica a gosto do cliente mesmo.
Um abraço.
GOSTEI 2
Mais Respostas
Lucas Ramos
04/05/2015
Acredito não fazer muita diferença, o que eu faria, criaria uma tabela NIVEL_ENTIDADE com os registros 1 - Usuário Comum, 2 - Usuário Moderador e 3 - Usuário Administrador., Id e Descrição e na tabela que fosse utilizar esses códigos criaria uma FK com referência a NIVEL_ENTIDADE, assim guardaria como int e impediria que outro programador tente usar um número diferente, e caso um dia precise consultar ou até mesmo retornar esse dado em uma consulta só utilizar um join para fazer a relação e pegar a descrição, não precisando chumbar nada no código.
GOSTEI 1
Thiago Santana
04/05/2015
Char ocupa menos espaço de armazenamento!
GOSTEI 0
Thiago Santana
04/05/2015
CHAR ocupa menos espaço de armazenamento!
GOSTEI 1
Jothaz
04/05/2015
Só uma coisa que não foi lembrada é que se você usar CHAR(1) é melhor ter certeza que vão existir menos de 10 grupos, senão terá de mudar para CHAR(2) na estrutura.
Nesta cado o indicado é usar números INT, TINYINT ou SMALLINT.
CHAR acho mais indicado para campos com conteúdos texto por exemplo Sigla UF.
Nesta cado o indicado é usar números INT, TINYINT ou SMALLINT.
CHAR acho mais indicado para campos com conteúdos texto por exemplo Sigla UF.
GOSTEI 0
Marilia Silva
04/05/2015
Pessoal, char não seria mais indicado para valores M e F(Masculino ou Feminino), no caso do post não seria melhor o int?
GOSTEI 0
Jothaz
04/05/2015
Pessoal, char não seria mais indicado para valores M e F(Masculino ou Feminino), no caso do post não seria melhor o int?
É por ai mesmo.
Agora como ressaltei neste caso o indicado é usar números INT, TINYINT ou SMALLINT.
GOSTEI 0
Marilia Silva
04/05/2015
Por ser mais de 2 opções?
GOSTEI 0
Jothaz
04/05/2015
Por ser mais de 2 opções?
No exemplo do post possivelmente a quantidade de itens da tabela não cresceria, porém por acaso ultrapassasse a quantidade de 9 itens teria de se alterar o tamanho do campo o que provoca uma mudança estrutural que não são nada agradavél.
Você deve usar o tipo de acordo com o conteúdo, se vai gravar número o indicado seria usar alguns dos tipos numérios que mencionei.
Quando você usa tipos númericos (INT, TINYINT ou SMALLINT) as consultas ficariam assim:
Select * from tabela where CRUPO_ID = 1
Se utilizar CHAR assim:
Select * from tabela where CRUPO_ID = '1'
Usando tipo numérico a query fica mais simples e legivel além de garantir uma melhor perfomance.
Com relação a utilização do CHAR seria indicado para guardar valores do tipo string (texto) que voce tenha certeza que não aumentarão. Por exemplo:
SEXO (genero) -> 'F' ou 'M' (sem ser sexista) e mesmo que surja um teceiro não afeta a estrutura
SIGLA UF -> 'SP', 'BA'...
VOGAIS -> 'a', 'e' ....
TIPO PESSOA -> 'F' ou 'J'
Uma preocupação seria o espaço usado para armazenar cada tipo, como o Joel destacou, o que depende de cada cenário. Muitas das vezes nem se faz necessário este tipo de preocupação.
GOSTEI 1
Jeremias Bastos
04/05/2015
Obrigado a todos cheguei a uma conclusão. TINYINT(1) equivalendo respectivamente a "1" - Usuário Comum, "2" - Usuário Moderador, "3" - Usuário Administrador.
GOSTEI 0
Jeremias Bastos
04/05/2015
Obrigado! Por acaso você tem algum documento onde tenha uma citação dizendo que o MySQL tem maior desempenho quando trabalha com TINYINT, ou números inteiros?
GOSTEI 0
Marilia Silva
04/05/2015
Li algo a respeito dos estados (UF) só não lembro aonde, é mais simples por ser um numero determinado de estados.
GOSTEI 0
Marilia Silva
04/05/2015
Li algo a respeito dos estados (UF) só não lembro aonde, é mais simples por ser um numero determinado de estados.
GOSTEI 0
Jothaz
04/05/2015
Obrigado! Por acaso você tem algum documento onde tenha uma citação dizendo que o MySQL tem maior desempenho quando trabalha com TINYINT, ou números inteiros?
Acho que se existir alguma diferença é irrelevante.
Só se sua aplicação for manipular bilhões de registros e acessos concorrentes.
GOSTEI 0