Campos comunes de MySQL y sus tipos de datos apropiados

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 por 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 campos de uso común como estos. Por ejemplo, he determinado que un número de teléfono de EE. UU. Sin formato es demasiado grande para ser almacenado como un int sin firmar, debe ser al menos un bigint.

Debido a que estoy seguro de que a otras personas probablemente les resultará útil, no quiero restringir mi pregunta a los campos que mencioné anteriormente.

¿Qué tipos de datos son apropiados para campos comunes de bases de datos? ¿Campos como número de teléfono, correo electrónico y dirección?

Alguien va a publicar una respuesta mucho mejor que esta, pero solo quería dejar claro que personalmente nunca almacenaría un número de teléfono en ningún tipo de campo entero, principalmente porque:

1. No necesitas hacer ningún tipo de aritmética con él, y
2. Tarde o temprano alguien intentará (hacer algo como) poner entre paréntesis su código de área.

Sin embargo, en general, parece que uso casi exclusivamente:

• INT (11) para cualquier cosa que sea una ID o haga referencia a otra ID
• DATETIME para marcas de tiempo
• VARCHAR (255) para cualquier cosa garantizada que tenga menos de 255 caracteres (títulos de página, nombres, etc.)
• TEXT 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 un profesional):

| 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       

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 siempre deben tratarse como texto, no como números. La razón habitual es que existen 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 resultan estar compuestos de dígitos numéricos (y eso es ignorar países como Canadá que tienen letras en sus códigos postales). Así que guárdelos en un campo de texto.

En MySQL puede utilizar campos VARCHAR para este tipo de información. Si bien suena perezoso, significa que no tiene que preocuparse demasiado por el tamaño mínimo correcto.

Dado que tratará con datos de longitud variable (nombres, direcciones de correo electrónico), entonces querrá usar VARCHAR. La cantidad de espacio que ocupa un campo VARCHAR es [field length]+ 1 bytes, 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, luego duplíquela y establezca eso como su límite VARCHAR. Dicho eso ...:

Por lo general, configuro los campos de correo electrónico para que sean VARCHAR (100); todavía no he encontrado ningún problema con eso. Nombres que establecí en VARCHAR (50).

Como han dicho los demás, los números de teléfono y los códigos postales no son en realidad valores numéricos, son cadenas que contienen los dígitos del 0 al 9 (¡y a veces más!) Y, por lo tanto, debe tratarlos como una cadena. VARCHAR (20) debería ser suficiente.

Tenga en cuenta que si tuviera que almacenar números de teléfono como enteros, muchos sistemas asumirá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".

Estoy haciendo lo mismo y esto es lo que hice.

Usé tablas separadas para el nombre, la dirección, el correo electrónico y los números, cada una con una columna NameID que es una clave externa en todo excepto en la tabla Name, en la que es la clave agrupada principal. Usé MainName y FirstName en lugar de LastName y FirstName para permitir entradas comerciales y personales, pero es posible que no lo necesite.

La columna NameID llega a ser un pequeño número 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 realmente depende 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 hablé de NameID. El número de teléfono es varchar (12) con una restricción de verificación que se parece a esto: 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 ingrese a la base de datos y que los datos se mantengan muy consistentes. Los códigos de extensión y de país los llamé pequeños que aceptan valores NULL, pero esos podrían ser varchar si quisieras. PhoneType es varchar (20) y no admite nulos.

¡Espero que esto ayude!