telefono - Campos comunes de MySQL y sus tipos de datos apropiados
tipos de datos en mysql workbench (5)
Estoy configurando una base de datos MySQL muy pequeña que almacena, nombre, apellido, correo electrónico y número de teléfono y estoy luchando para encontrar el tipo de datos ''perfecto'' para cada campo. Sé que no existe una respuesta perfecta, pero debe haber algún tipo de convención común para los campos comúnmente utilizados como estos. Por ejemplo, he determinado que un número de teléfono de EE. UU. No formateado es demasiado grande para almacenarlo como un int sin firmar, debe ser al menos un bigint.
Como estoy seguro de que otras personas probablemente lo encuentren útil, no quiero limitar mi pregunta a los campos que mencioné anteriormente.
¿Qué tipos de datos son apropiados para los campos de base de datos comunes? ¿Campos como el número de teléfono, el correo electrónico y la dirección?
Alguien va a publicar una respuesta mucho mejor que esta, pero solo quería dejar en claro que personalmente nunca almacenaría un número de teléfono en ningún tipo de campo entero, principalmente porque:
- No necesita hacer ningún tipo de aritmética con él, y
- Tarde o temprano, alguien intentará (hacer algo como) poner corchetes alrededor de su código de área.
En general, parece que uso casi exclusivamente:
- INT (11) para cualquier cosa que sea una ID o que haga referencia a otra ID
- DATETIME para las marcas de tiempo
- VARCHAR (255) para cualquier cosa que garantice tener menos de 255 caracteres (títulos de página, nombres, etc.)
- TEXTO para casi todo lo demás.
Por supuesto que hay excepciones, pero creo que cubre la mayoría de las eventualidades.
Aquí hay algunos tipos de datos comunes que uso (aunque no soy muy pro):
| 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
Como va a tratar con datos de una longitud variable (nombres, direcciones de correo electrónico), querrá usar VARCHAR. La cantidad de espacio ocupada por un campo VARCHAR es [field length] + 1 byte, hasta una longitud máxima de 255, por lo que no me preocuparía demasiado por tratar de encontrar un tamaño perfecto. Eche un vistazo a lo que imagina que podría ser la longitud más larga posible, luego duplíquelo y configúrelo como su límite VARCHAR. Dicho eso ...
En general, configuro los campos de correo electrónico para que sean VARCHAR (100); todavía no he encontrado un problema. Nombres que configuré para VARCHAR (50).
Como han dicho los otros, los números de teléfono y los códigos postal no son valores numéricos, son cadenas que contienen los dígitos 0-9 (¡y algunas veces más!), Por lo que debe tratarlos como una cadena. VARCHAR (20) debería ser suficiente.
Tenga en cuenta que si almacene números de teléfono como números enteros, muchos sistemas supondrán que un número que comienza con 0 es un número octal (base 8). Por lo tanto, el número de teléfono perfectamente válido "0731602412" se pondría en su base de datos como el número decimal "124192010" !!
En mi experiencia, los campos de nombre / apellido deben tener al menos 48 caracteres; hay nombres de algunos países como Malasia o India que son muy largos en su forma completa.
Los números de teléfono y los códigos postales deben tratarse siempre como texto, no como números. La razón normal es que hay códigos postales que comienzan con 0, y en algunos países, los números de teléfono también pueden comenzar con 0. Pero la verdadera razón es que no son números , son identificadores que se han inventado. de dígitos numéricos (y eso está ignorando países como Canadá que tienen letras en sus códigos postales). Así que guárdalos en un campo de texto.
En MySQL puede usar los campos VARCHAR para este tipo de información. Si bien suena flojo, significa que no tiene que preocuparse demasiado por el tamaño mínimo correcto.
Estoy haciendo lo mismo, y esto es lo que hice.
Utilicé tablas separadas para el nombre, la dirección, el correo electrónico y los números, cada uno con una columna NameID que es una clave externa en todo excepto en la tabla Nombre, en la que es la clave principal agrupada. Usé MainName y FirstName en lugar de LastName y FirstName para permitir las entradas comerciales, así como las entradas personales, pero es posible que no lo necesite.
La columna NameID llega a ser una pequeña impronta en todas las tablas porque estoy bastante seguro de que no haré más de 32000 entradas. Casi todo lo demás es varchar (n) que va de 20 a 200, dependiendo de lo que quieras almacenar (cumpleaños, comentarios, correos electrónicos, nombres realmente largos). Eso es realmente dependiente del tipo de cosas que estás almacenando.
La tabla de Números es donde me desvío de eso. Lo configuré para tener cinco columnas etiquetadas NameID, Phone #, CountryCode, Extension y PhoneType. Ya discutí NameID. El número de teléfono es varchar (12) con una restricción de verificación que se ve así: CHECK (Número de teléfono como ''[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] ''). Esto asegura que solo lo que quiero se inserta en la base de datos y la información se mantiene muy consistente. La extensión y los códigos de país los llamé smallints nulables, pero podrían ser varchar si así lo quisieran. PhoneType es varchar (20) y no puede contener nulos.
¡Espero que esto ayude!