Campi MySQL comuni e relativi tipi di dati appropriati

Sto configurando un database MySQL molto piccolo che memorizza nome, cognome, e-mail e numero di telefono e sto lottando per trovare il tipo di dati "perfetto" per ogni campo. So che non esiste una risposta perfetta, ma deve esserci una sorta di convenzione comune per campi di uso comune come questi. Ad esempio, ho determinato che un numero di telefono statunitense non formattato è troppo grande per essere memorizzato come int non firmato, deve essere almeno un bigint.

Poiché sono sicuro che altre persone probabilmente lo troverebbero utile, non voglio limitare la mia domanda solo ai campi che ho menzionato sopra.

Quali tipi di dati sono appropriati per i campi di database comuni? Campi come numero di telefono, e-mail e indirizzo?

Qualcuno pubblicherà una risposta molto migliore di questa, ma volevo solo sottolineare che personalmente non avrei mai memorizzato un numero di telefono in nessun tipo di campo intero, principalmente perché:

1. Non è necessario eseguire alcun tipo di aritmetica con esso, e
2. Prima o poi qualcuno proverà a (fare qualcosa di simile) a mettere parentesi attorno al proprio prefisso.

In generale, però, mi sembra di usare quasi esclusivamente:

• INT (11) per tutto ciò che è un ID o fa riferimento a un altro ID
• DATETIME per timestamp
• VARCHAR (255) per tutto ciò che deve contenere meno di 255 caratteri (titoli di pagina, nomi, ecc.)
• TESTO praticamente per tutto il resto.

Ovviamente ci sono delle eccezioni, ma trovo che copra la maggior parte delle eventualità.

Ecco alcuni tipi di dati comuni che uso (non sono un gran professionista però):

| 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       

Nella mia esperienza, i campi del nome / cognome dovrebbero contenere almeno 48 caratteri: ci sono nomi di alcuni paesi come la Malesia o l'India che sono molto lunghi nella loro forma completa.

Numeri di telefono e codici postali che dovresti sempre considerare come testo, non come numeri. Il motivo normale addotto è che ci sono codici postali che iniziano con 0 e, in alcuni paesi, anche i numeri di telefono possono iniziare con 0. Ma il vero motivo è che non sono numeri : sono identificatori inventati di cifre numeriche (e questo ignorando paesi come il Canada che hanno lettere nei loro codici postali). Quindi memorizzali in un campo di testo.

In MySQL puoi usare i campi VARCHAR per questo tipo di informazioni. Anche se sembra pigro, significa che non devi preoccuparti troppo della giusta dimensione minima.

Dal momento che avrai a che fare con dati di lunghezza variabile (nomi, indirizzi e-mail), allora vorrai usare VARCHAR. La quantità di spazio occupata da un campo VARCHAR è [field length]+ 1 byte, fino alla lunghezza massima 255, quindi non mi preoccuperei troppo di cercare una dimensione perfetta. Dai un'occhiata a quella che potresti immaginare potrebbe essere la lunghezza più lunga, quindi raddoppiala e impostala come limite VARCHAR. Detto ciò...:

In genere imposto i campi e-mail su VARCHAR (100) - non ho ancora riscontrato alcun problema. Nomi che ho impostato su VARCHAR (50).

Come hanno già detto gli altri, i numeri di telefono e i codici postali non sono in realtà valori numerici, sono stringhe contenenti le cifre 0-9 (e talvolta anche di più!), E quindi dovresti trattarli come una stringa. VARCHAR (20) dovrebbe essere ben sufficiente.

Nota che se dovessi memorizzare i numeri di telefono come numeri interi, molti sistemi presumeranno che un numero che inizia con 0 sia un numero ottale (base 8)! Pertanto, il numero di telefono perfettamente valido "0731602412" verrebbe inserito nel database come numero decimale "124192010" !!

Sto facendo più o meno la stessa cosa, ed ecco cosa ho fatto.

Ho usato tabelle separate per nome, indirizzo, e-mail e numeri, ciascuna con una colonna NameID che è una chiave esterna su tutto tranne la tabella Name, in cui è la chiave cluster primaria. Ho usato MainName e FirstName invece di LastName e FirstName per consentire voci aziendali e personali, ma potresti non averne bisogno.

La colonna NameID diventa un piccolo in tutte le tabelle perché sono abbastanza certo che non inserirò più di 32000 voci. Quasi tutto il resto è varchar (n) che va da 20 a 200, a seconda di cosa si desidera memorizzare (compleanni, commenti, e-mail, nomi molto lunghi). Questo dipende davvero dal tipo di cose che stai memorizzando.

La tabella dei numeri è dove mi discosto da quello. L'ho impostato per avere cinque colonne etichettate NameID, Phone #, CountryCode, Extension e PhoneType. Ho già discusso di NameID. Phone # è varchar (12) con un vincolo di controllo simile a questo: CHECK (Phone # like '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Ciò garantisce che solo ciò che desidero venga inserito nel database e che i dati rimangano molto coerenti. L'estensione e i codici paese che ho chiamato nullable smallints, ma quelli potrebbero essere varchar se lo desideri. PhoneType è varchar (20) e non annulla.

Spero che questo ti aiuti!