campos MySQL comuns e seus tipos de dados apropriados

votos
96

Estou configurando um pequeno banco de dados MySQL que armazena, primeiro nome, sobrenome, e-mail e número de telefone e estou lutando para encontrar o tipo de dados 'perfeito' para cada campo. Eu sei que não existe tal coisa como uma resposta perfeita, mas deve haver algum tipo de convenção comum para campos comumente usados ​​como estas. Por exemplo, eu determinei que um número de telefone não formatado EUA é muito grande para ser armazenado como um int não assinado, deve ser no mínimo um bigint.

Porque eu tenho certeza outras pessoas provavelmente encontrar este útil, eu não quero para restringir a minha pergunta para apenas os campos que eu mencionei acima.

Que tipos de dados são apropriados para os campos de banco de dados comuns? Campos como número de telefone, e-mail e endereço?

Publicado 10/12/2008 em 01:48
fonte usuário
Em outras línguas...                            


5 respostas

votos
59

Alguém está indo para postar uma resposta muito melhor do que isso, mas só queria fazer o ponto que, pessoalmente, eu nunca iria armazenar um número de telefone em qualquer tipo de campo inteiro, principalmente porque:

  1. Você não precisa fazer qualquer tipo de aritmética com ele, e
  2. Mais cedo ou mais tarde alguém vai tentar (fazer algo assim) colocar colchetes em torno de seu código de área.

Em geral, porém, parece que eu uso quase exclusivamente:

  • INT (11) para qualquer coisa que seja um ID ou referências outro ID
  • DATETIME para selos de tempo
  • VARCHAR (255) para qualquer coisa garantido para ser menos de 255 caracteres (títulos de página, nomes, etc.)
  • TEXTO para praticamente tudo o resto.

Claro que existem exceções, mas eu acho que abrange a maioria das eventualidades.

Respondeu 10/12/2008 em 01:57
fonte usuário

votos
25

Aqui estão alguns tipos de dados comuns que eu uso (eu não sou muito de um profissional embora):

| Column           | Data type     | Note
| ---------------- | ------------- | -------------------------------------
| id               | INTEGER       | AUTO_INCREMENT, UNSIGNED                                                          |  
| uuid             | CHAR(36)      | or CHAR(16) binary                                                                |  
| title            | VARCHAR(255)  |                                                                                   |  
| full name        | VARCHAR(70)   |                                                                                   |  
| gender           | TINYINT       | UNSIGNED                                                                          |  
| description      | TINYTEXT      | often may not be enough, use TEXT 
                                     instead          
| post body        | TEXT          |                                                                                   |  
| email            | VARCHAR(255)  |                                                                                   |  
| url              | VARCHAR(2083) | MySQL version < 5.0.3 - use TEXT                                                  |  
| salt             | CHAR(x)       | randomly generated string, usually of 
                                     fixed length (x)    
| digest (md5)     | CHAR(32)      |                                                                                   |  
| phone number     | VARCHAR(20)   |                                                                                   |  
| US zip code      | CHAR(5)       | Use CHAR(10) if you store extended 
                                     codes      
| US/Canada p.code | CHAR(6)       |                                                                                   |  
| file path        | VARCHAR(255)  |                                                                                   |  
| 5-star rating    | DECIMAL(3,2)  | UNSIGNED                                                                          |  
| price            | DECIMAL(10,2) | UNSIGNED                                                                          |  
| date (creation)  | DATE/DATETIME | usually displayed as initial date of 
                                     a post                                       |  
| date (tracking)  | TIMESTAMP     | can be used for tracking changes in a 
                                     post                                        |  
| tags, categories | TINYTEXT      | comma separated values *                                                          |  
| status           | TINYINT(1)    | 1 – published, 0 – unpublished, … You 
                                     can also use ENUM for human-readable 
                                     values
| json data        | JSON          | or LONGTEXT       
Respondeu 29/12/2009 em 00:40
fonte usuário

votos
14

Na minha experiência, os primeiros campos de nome / sobrenome deve ser pelo menos 48 caracteres - há nomes de alguns países como a Malásia ou a Índia, que são muito longa em sua forma completa.

Números de telefone e códigos postais você deve sempre tratar como texto, não números. A razão normal, dada é que existem códigos postais que começam com 0 e, em alguns países, números de telefone também pode começar com 0. Mas a verdadeira razão é que eles não são números - eles são identificadores que acontecem a ser feita de dígitos numéricos (e que países como o Canadá que têm letras em seus códigos postais ignorando). Então, armazená-los em um campo de texto.

No MySQL você pode usar campos VARCHAR para este tipo de informação. Enquanto isso soa preguiçoso, isso significa que você não tem que estar muito preocupado com o tamanho mínimo direito.

Respondeu 10/12/2008 em 02:01
fonte usuário

votos
8

Desde que você vai ser lidar com dados de comprimento variável (nomes, endereços de email), então você estaria querendo usar VARCHAR. A quantidade de espaço ocupado por um campo VARCHAR é [field length]+ 1 bytes, até ao comprimento máximo de 255, então eu não me preocuparia muito sobre a tentativa de encontrar um tamanho perfeito. Dê uma olhada no que você imagina pode ser o maior comprimento pode ser, então dobrá-lo e defina-o como o seu limite de VARCHAR. Dito isto...:

Eu geralmente definir os campos de e-mail para ser VARCHAR (100) - Eu não vim com um problema de que ainda. Nomes I definido para VARCHAR (50).

Como os outros disseram, números de telefone e códigos Zip / Postal na verdade não são valores numéricos, eles são strings contendo os dígitos 0-9 (e às vezes mais!), E, ​​portanto, você deve tratá-los como uma string. VARCHAR (20) deve ser suficiente bem.

Note que se você fosse para armazenar números de telefone como números inteiros, muitos sistemas irá assumir que um número começando com 0 é um (base 8) número octal! Portanto, o número de telefone perfeitamente válido "0731602412" iria se colocar em seu banco de dados como o número decimal "124192010" !!

Respondeu 10/12/2008 em 02:08
fonte usuário

votos
1

Eu estou fazendo sobre a mesma coisa, e aqui está o que eu fiz.

Eu usei tabelas separadas para o nome, endereço, e-mail e números, cada um com uma coluna NameID que é uma chave estrangeira em tudo, exceto a tabela de nomes, em que é a chave de cluster primário. Eu costumava MainName e FirstName vez de LastName e FirstName para permitir entradas de negócios, bem como entradas pessoais, mas você não pode ter uma necessidade para isso.

A coluna NameID chega a ser um smallint em todas as mesas porque estou bastante certo de que não vai fazer mais de 32000 entradas. Quase tudo o resto é varchar (n) variando de 20 a 200, dependendo do que você quer armazenar (aniversários, comentários, e-mails, nomes realmente longos). Isso é realmente dependente do tipo de material que você está armazenando.

A tabela de números é onde desviar-se que. Eu configurá-lo para ter cinco colunas rotuladas NameID, Telefone, CountryCode, Extensão e PHONETYPE. Eu já discutido NameID. Telefone é varchar (12) com um algo restrição de verificação parecido com isto: CHECK (telefone #, como '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Isso garante que só o que eu quero faz-lo no banco de dados e os dados permanecem muito consistente. Os códigos de extensão e do país I chamado smallints anuláveis, mas aqueles poderia ser varchar se você quisesse. PHONETYPE é VARCHAR (20) e não é nulo.

Espero que isto ajude!

Respondeu 26/02/2010 em 06:13
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more