Загальні поля MySQL та їх відповідні типи даних

Я створюю дуже маленьку базу даних MySQL, яка зберігає ім’я, прізвище, електронну пошту та номер телефону і намагаюся знайти «ідеальний» тип даних для кожного поля. Я знаю, що немає такої ідеї, як ідеальна відповідь, але для загальновживаних полів, таких як така, повинна бути якась загальна конвенція. Наприклад, я визначив, що неоформлений номер телефону в США занадто великий, щоб зберігати його як непідписаний int, він повинен бути як мінімум bigint.

Оскільки я впевнений, що інші люди, мабуть, вважають це корисним, я не хочу обмежувати своє питання лише полями, про які я згадував вище.

Які типи даних підходять для загальних полів баз даних? Такі поля, як номер телефону, електронна адреса та адреса?

Хтось збирається опублікувати набагато кращу відповідь, ніж це, але просто хотів зробити так, що особисто я ніколи не зберігатиму номер телефону в якомусь цілому полі, головним чином тому, що:

1. Вам не потрібно робити якісь арифметики з ним, і
2. Рано чи пізно хтось спробує (зробити щось подібне) поставити дужки навколо свого коду.

Взагалі, хоча, я, здається, майже виключно використовую:

• INT (11) для всього, що є або ідентифікатором, або посиланням на інший ідентифікатор
• ДАТЕТИМ для часових позначок
• VARCHAR (255) за все, що гарантовано міститиме менше 255 символів (назви сторінок, імена тощо)
• ТЕКСТ для майже всього іншого.

Звичайно, є винятки, але я вважаю, що це стосується більшості випадків.

Ось декілька поширених типів даних, які я використовую (я не дуже професіонал):

| 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       

На мій досвід, поля імені / прізвища мають містити принаймні 48 символів - є імена з деяких країн, таких як Малайзія чи Індія, які дуже довгі в повному вигляді.

Номери телефонів та поштові індекси, які завжди слід розглядати як текст, а не цифри. Звичайною причиною є те, що є поштові індекси, які починаються з 0, а в деяких країнах номери телефонів також можуть починатися з 0. Але справжня причина - це не номери - це ідентифікатори, які, як правило, складаються числових цифр (і це ігнорування країн, таких як Канада, які мають букви в своїх поштових індексах). Тому зберігайте їх у текстовому полі.

У MySQL ви можете використовувати поля VARCHAR для цього типу інформації. Хоча це звучить ліниво, це означає, що вам не потрібно надто перейматися правильним мінімальним розміром.

Оскільки ви збираєтесь мати справу з даними різної довжини (імена, адреси електронної пошти), тоді ви хочете використовувати VARCHAR. Кількість місця, яке займає поле VARCHAR, становить [field length]+ 1 байт, максимальна довжина 255, тому я б не переймався над тим, щоб намагатися знайти ідеальний розмір. Погляньте на те, що, на вашу думку, може бути найдовша довжина, а потім подвойте його та встановіть це як обмеження VARCHAR. Це сказав ...:

Як правило, поля електронної пошти встановлюються як VARCHAR (100) - я з цим ще не зіткнувся з проблемою. Імена я встановив VARCHAR (50).

Як говорили інші, телефонні номери та поштові індекси насправді не є числовими значеннями, вони є рядками, що містять цифри 0-9 (а іноді й більше!), І тому слід ставитися до них як до рядка. VARCHAR (20) повинен бути достатньою.

Зауважте, що якби ви зберігали телефонні номери як цілі числа, багато систем припускають, що число, що починається з 0, є восьмеричним (базовим 8) числом! Тому ідеально дійсний номер телефону "0731602412" потрапить у вашу базу даних у вигляді десяткового номера "124192010" !!

Я роблю приблизно те саме, і ось що я зробив.

Я використовував окремі таблиці для імені, адреси, електронної пошти та номерів, у кожній із стовпців NameID, які є іноземним ключем у всьому, крім таблиці Імен, в якій це первинний кластерний ключ. Я використовував MainName та FirstName замість LastName та FirstName, щоб дозволити як бізнес-записи, так і особисті записи, але у вас, можливо, не буде потреби в цьому.

Стовпець NameID повинен бути малим у всіх таблицях, тому що я впевнений, що я не буду робити більше 32000 записів. Майже все інше - варчар (n), що становить від 20 до 200, залежно від того, що ви хочете зберігати (дні народження, коментарі, електронні листи, дійсно довгі імена). Це дійсно залежить від того, які речі ви зберігаєте.

Таблиця цифр - це те, де я відхиляюсь від цього. Я встановив це п'ять стовпців з написом NameID, Phone #, CountryCode, Extension та PhoneType. Я вже обговорював NameID. Телефон # - це varchar (12) з обмеженням чека, виглядаючи приблизно так: ПЕРЕВІРИТИСЯ (Телефон # як '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Це гарантує, що лише те, що я хочу, перетворює його в базу даних, а дані залишаються дуже послідовними. Розширення та коди країн я назвав нульовими дрібними шрифтами, але вони можуть бути варчарними, якщо хочете. PhoneType варчар (20) і не зводиться до нуля.

Сподіваюся, це допомагає!