Typowe pola MySQL i ich odpowiednie typy danych

Konfiguruję bardzo małą bazę danych MySQL, która przechowuje imię, nazwisko, adres e-mail i numer telefonu i staram się znaleźć „idealny” typ danych dla każdego pola. Wiem, że nie ma czegoś takiego jak idealna odpowiedź, ale musi istnieć jakaś wspólna konwencja dla powszechnie używanych dziedzin, takich jak te. Na przykład ustaliłem, że niesformatowany numer telefonu w USA jest zbyt duży, aby można go było zapisać jako int bez znaku, musi to być co najmniej bigint.

Ponieważ jestem pewien, że inne osoby prawdopodobnie uznają to za przydatne, nie chcę ograniczać mojego pytania tylko do pól, o których wspomniałem powyżej.

Jakie typy danych są odpowiednie dla wspólnych pól baz danych? Pola takie jak numer telefonu, e-mail i adres?

Ktoś zamieści znacznie lepszą odpowiedź niż ta, ale chciałem tylko zaznaczyć, że osobiście nigdy nie przechowywałbym numeru telefonu w jakimkolwiek polu liczb całkowitych, głównie dlatego, że:

1. Nie musisz wykonywać na nim żadnych działań arytmetycznych i
2. Wcześniej czy później ktoś spróbuje (zrobić coś takiego), aby umieścić nawiasy wokół numeru kierunkowego.

Generalnie jednak wydaje mi się, że używam prawie wyłącznie:

• INT (11) dla wszystkiego, co jest identyfikatorem lub odwołuje się do innego identyfikatora
• DATETIME dla znaczników czasu
• VARCHAR (255) dla wszystkiego, co ma mniej niż 255 znaków (tytuły stron, nazwy itp.)
• TEKST na prawie wszystko inne.

Oczywiście są wyjątki, ale uważam, że obejmuje to większość ewentualności.

Oto kilka typowych typów danych, których używam (chociaż nie jestem wielkim profesjonalistą):

| 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       

Z mojego doświadczenia wynika, że ​​pola imię / nazwisko powinny mieć co najmniej 48 znaków - są nazwy z niektórych krajów, takich jak Malezja czy Indie, które są bardzo długie w pełnej formie.

Numery telefonów i kody pocztowe należy zawsze traktować jako tekst, a nie liczby. Podawanym normalnym powodem jest to, że istnieją kody pocztowe zaczynające się od 0, aw niektórych krajach numery telefonów mogą również zaczynać się od 0. Ale prawdziwym powodem jest to, że nie są to cyfry - to identyfikatory, które zdarzają się składać cyfr (i to ignoruje kraje takie jak Kanada, które mają litery w swoich kodach pocztowych). Więc przechowuj je w polu tekstowym.

W MySQL możesz używać pól VARCHAR dla tego typu informacji. Chociaż brzmi to leniwie, oznacza to, że nie musisz się zbytnio przejmować odpowiednim minimalnym rozmiarem.

Ponieważ będziesz mieć do czynienia z danymi o zmiennej długości (imiona i nazwiska, adresy e-mail), chciałbyś użyć VARCHAR. Ilość miejsca zajmowanego przez pole VARCHAR to [field length]+ 1 bajt, do maksymalnej długości 255, więc nie przejmowałbym się zbytnio próbą znalezienia idealnego rozmiaru. Spójrz na to, jaka może być najdłuższa długość, którą możesz sobie wyobrazić, a następnie podwoj ją i ustaw jako swój limit VARCHAR. To mówi...:

Generalnie ustawiam pola e-mail na VARCHAR (100) - jeszcze nie mam z tym problemu. Nazwy, które ustawiłem na VARCHAR (50).

Jak powiedzieli inni, numery telefonów i kody pocztowe / pocztowe nie są w rzeczywistości wartościami liczbowymi, są to ciągi znaków zawierające cyfry 0-9 (a czasem więcej!), Dlatego należy je traktować jako ciąg. VARCHAR (20) powinien być wystarczający.

Zauważ, że gdybyś zapisywał numery telefonów jako liczby całkowite, wiele systemów założyłoby, że liczba zaczynająca się od 0 jest liczbą ósemkową (podstawa 8)! Dlatego doskonale poprawny numer telefonu „0731602412” zostałby umieszczony w Twojej bazie danych jako liczba dziesiętna „124192010” !!

Robię mniej więcej to samo i oto co zrobiłem.

Użyłem oddzielnych tabel dla nazwy, adresu, adresu e-mail i liczb, z których każda zawierała kolumnę NameID, która jest kluczem obcym dla wszystkiego, z wyjątkiem tabeli Name, w której jest to podstawowy klucz klastrowy. Użyłem MainName i FirstName zamiast LastName i FirstName, aby umożliwić wpisy biznesowe, a także osobiste, ale możesz nie mieć takiej potrzeby.

Kolumna NameID staje się smallint we wszystkich tabelach, ponieważ jestem prawie pewien, że nie zrobię więcej niż 32000 wpisów. Prawie wszystko inne to varchar (n), od 20 do 200, w zależności od tego, co chcesz przechowywać (urodziny, komentarze, e-maile, naprawdę długie nazwiska). To naprawdę zależy od rodzaju przechowywanych rzeczy.

Odchodzę od tego w tabeli liczb. Ustawiłem go tak, aby miał pięć kolumn z etykietami NameID, Phone #, CountryCode, Extension i PhoneType. Omówiłem już NameID. Numer telefonu to varchar (12) z ograniczeniem sprawdzającym wyglądającym mniej więcej tak: CHECK (numer telefonu, taki jak „[0-9] [0-9] [0-9] - [0-9] [0-9] [0] -9] - [0-9] [0-9] [0-9] [0-9] '). Gwarantuje to, że tylko to, czego chcę, trafia do bazy danych, a dane pozostają bardzo spójne. Kody rozszerzenia i krajów, które nazwałem nullable smallints, ale jeśli chcesz, mogą to być varchar. PhoneType to varchar (20) i nie dopuszcza wartości null.

Mam nadzieję że to pomoże!