Persistir telefone, qual o tipo de dado mais indicado?

Programação Java
#1

Estou usando Hibernate.

Qual tipo de dado é mais indicado para armazenar um telefone com oito dígitos? Estou usando Long, mas já vi pessoas usarem String para tal situação. O que acham?

Obrigado,
Felipe

#2

A não ser que vc queira validar o numero de telefone, vá de Varchar para o DB e String para Java

eu utilizo um varchar, pq armazeno desta forma --> (65)3223-8454

:stuck_out_tongue:

#3

Integer resolve.

#4

Dica: para qualquer informação que não será utilizada em cálculos, utilize CHAR ou VARCHAR.

#5

Esqueci de mencionar que gravo o DDD também, portanto para um tipo númerico tem que ser Long mesmo.

Para persistência, tenho outras duas dúvidas quanto ao uso de VARCHAR.

  • Não vou precisar de letras
  • Custo computacional mais alto?
#6

[quote=FkJ]Esqueci de mencionar que gravo o DDD também, portanto para um tipo númerico tem que ser Long mesmo.

Para persistência, tenho outras duas dúvidas quanto ao uso de VARCHAR.

  • Não vou precisar de letras
  • Custo computacional mais alto?[/quote]

Não faz besteira. Telefone é varchar.
Não precisará de letras necessariamente, basta gravar Strings. ex: “123 (456) - 789”
Custo mais alto? Cara não viaja… :smiley:

#7

[quote=peerless]
Não faz besteira. Telefone é varchar.
Não precisará de letras necessariamente, basta gravar Strings. ex: “123 (456) - 789”
Custo mais alto? Cara não viaja… :D[/quote]

disse tudo…

varchar( 8 ) resolve! se for gravar o ddd varchar(10)

eu ainda gravaria o ddd em outra coluna… mas se não é o seu caso, varchar sem dúvidas…
acredito que vc não precise fazer cálculos com os números do telefone

#8

Acho q vc tem custo computacional mais alto quando converte um long em String na hora de apresentar esse valor… então deixe varchar no banco que ja fica sussegado… mas eu nao colocaria no formato (99)9999-9999 no banco… ta desperdiçando 3 bytes: ()- !!!
:smiley:
Varchar de 10 posições: 9999999999. Simples e rápido!!

#9

Eu também utilizaria Varchar.

Tanto porque você pode usar um JFormattedTextField, onde você criaria uma mascara obrigando ao usuário digitar somente números e salvando no banco de uma forma mais visível e prática…

Se você usar um integer ou um long… salvaria no banco da seguinte forma se tivesse o ddd junto :

1132365890

Já usando uma mascara ficaria mais ou menos assim

(11) 3236-5890

#10

Dêem uma “shiftada” em seus pensamentos. Afinal, para que se discutir se é String, long ou sei lá o que? A orientação a objetos serve para que?

O tipo de dado apropriado para telefone é: Telefone

public class Telephone {

    private short internationalCode;
    private short londDistanceCode;
    private short prefix;
    private short suffix;

    public Telephone(String telephoneNumber) {
        // converte a string recebida para os dados internos
    }
    
    public Telephone(long telephoneNumber) {
        // converte o número recebido para os dados internos
    }

    public String getAsString() {
        return "" + internationalCode + " (" + 
            londDistanceCode + ") " + prefix + "-" +
            suffix;
    }

    public Long getAsLong() {
        // transforma os atributos da classe em uma
        // representação numérica
    }

    // outros métodos úteis associados a telefone

}

A orientação a objetos é útil para encapsular a decisão de se usar long ou String. Não tenha medo de usar um objeto só porque acha que é “pequeno” ou “porque não está associado a pattern”.

[edit]
O método getAsLong() estava retornando String (quem manda não compilar!), corrigido.
[/edit]

#11

+1 pra tudo que o Leonardo disse. Mas eu usaria toString() e toLong() ao inves de getAsString() e getAsLong() - assim, quando vc for imprimir o telefone na UI, basta fingir que eh uma String e na maioria dos casos vai funcionar direitinho (se nao, que merda de framework vc ta usando? :slight_smile: )

#12

[quote] public String getAsLong() { // transforma os atributos da classe em uma // representação numérica } [/quote]

getAsLong() retornar String!?

#13

Valeu o aviso!

#14

Galera,
Primeiro gostaria de desculpar por “desenterrar” o tópico, mas esse é o mais próximo da minha dúvida.

Vamos lá.

Concordo com o pessoal que o telefone deve ser uma classe.
Tenho justamente esse cenário, um cliente cujo mesmo prossui um atributo do tipo “Telefone”.

Segue a classe (copiei essa mesmo de exemplo, só adicionei/alterei algumas coisas):

public class Telefone {

    private short internationalCode;
    private short londDistanceCode;
    private short prefix;
    private short suffix;

    public Telefone(String telephoneNumber) {
        // converte a string recebida para os dados internos
    }
    
    public Telefone(long telephoneNumber) {
        // converte o número recebido para os dados internos
    }

    public String getAsString() {
        return "" + internationalCode + " (" + 
            londDistanceCode + ") " + prefix + "-" +
            suffix;
    }

    public Long getAsLong() {
        // transforma os atributos da classe em uma
        // representação numérica
    }
	
    public String getTelefoneCompleto() {
        return "" + internationalCode + londDistanceCode + prefix + suffix;
    }
	
    public String setTelefoneCompleto(String telefoneCompleto) {
        // aqui ficaria a regra que dividiria o atributo "telefoneCompleto" para os demais.
    }
	
    // outros métodos úteis associados a telefone

}

Imagine que utilizamos o seguinte mapeamento:

@Embedded
@AttributeOverride (name="telefoneCompleto", column=@Column("TELEFONE"))
private Telefone;

Imagine que eu gostaria de ter o método “telefoneCompleto” como o que fará o “bind” com o banco.
Essa seria a melhor maneira de implementar?

#15