Общие поля MySQL и соответствующие им типы данных

Кто-то собирается опубликовать гораздо лучший ответ, чем этот, но просто хотел подчеркнуть, что лично я никогда не буду хранить номер телефона в каком-либо целочисленном поле, в основном потому, что:

1. С ним не нужно делать никаких арифметических операций, и
2. Рано или поздно кто-то попытается (сделать что-то вроде) заключить код города в скобки.

В целом, похоже, я почти исключительно использую:

• INT (11) для всего, что является идентификатором или ссылается на другой идентификатор
• DATETIME для отметок времени
• VARCHAR (255) для всего, что должно быть меньше 255 символов (заголовки страниц, имена и т. д.)
• ТЕКСТ почти для всего остального.

Конечно, есть исключения, но я считаю, что это покрывает большинство случаев.

По моему опыту, поля имени / фамилии должны содержать не менее 48 символов - есть имена из некоторых стран, таких как Малайзия или Индия, которые очень длинные в своей полной форме.

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

В MySQL вы можете использовать поля VARCHAR для этого типа информации. Хотя это звучит лениво, это означает, что вам не нужно слишком беспокоиться о правильном минимальном размере.

Поскольку вы собираетесь иметь дело с данными переменной длины (имена, адреса электронной почты), вам следует использовать VARCHAR. Объем пространства, занимаемого полем VARCHAR, составляет [field length] + 1 байт, до максимальной длины 255, поэтому я бы не стал слишком беспокоиться о попытках найти идеальный размер. Взгляните на то, что, по вашему мнению, может быть самой длинной длиной, затем удвойте ее и установите как предел VARCHAR. Тем не менее ...:

Я обычно устанавливаю поля электронной почты как VARCHAR (100) - у меня еще не возникла проблема. Имена я установил в VARCHAR (50).

Как говорили другие, номера телефонов и почтовые индексы на самом деле не являются числовыми значениями, это строки, содержащие цифры 0-9 (а иногда и больше!), И поэтому вы должны рассматривать их как строку. VARCHAR (20) должно быть вполне достаточно.

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

Вот некоторые распространенные типы данных, которые я использую (хотя я не особо профессионал):

| 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       

Я делаю примерно то же самое, и вот что я сделал.

Я использовал отдельные таблицы для имени, адреса, электронной почты и чисел, каждая со столбцом NameID, который является внешним ключом для всего, кроме таблицы Name, для которой он является первичным кластеризованным ключом. Я использовал MainName и FirstName вместо LastName и FirstName, чтобы разрешить как бизнес-записи, так и личные записи, но, возможно, вам это не понадобится.

Столбец NameID должен быть небольшим количеством во всех таблицах, потому что я почти уверен, что не сделаю больше 32000 записей. Почти все остальное - это varchar (n) в диапазоне от 20 до 200, в зависимости от того, что вы хотите сохранить (дни рождения, комментарии, электронные письма, действительно длинные имена). Это действительно зависит от того, какие данные вы храните.

Таблица чисел - вот где я отклоняюсь от этого. Я установил в нем пять столбцов с названиями NameID, Phone #, CountryCode, Extension и PhoneType. Я уже обсуждал NameID. Номер телефона - varchar (12) с проверочным ограничением, которое выглядит примерно так: CHECK (Phone # как '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Это гарантирует, что в базу данных попадет только то, что я хочу, и данные останутся согласованными. Коды расширения и страны я назвал обнуляемыми smallints, но при желании это может быть varchar. PhoneType имеет значение varchar (20) и не допускает значения NULL.

Надеюсь это поможет!

Любой идентификатор таблицы

Использование: INT(11).

Индексы MySQL сможет быстрее всего проанализировать список int.

Что-нибудь Безопасность

Используйте: BINARY(x) или BLOB(x).

Вы можете хранить токены безопасности и т. д. В шестнадцатеричном виде непосредственно в BINARY (x) или BLOB (x). Для извлечения из типа binary используйте SELECT HEX(field)... или SELECT ... WHERE field = UNHEX("ABCD....").

Что-нибудь Дата

Используйте: DATETIME, DATE или TIME.

Всегда используйте DATETIME, если вам нужно хранить как дату, так и время (вместо пары полей), поскольку индексация DATETIME более удобна для сравнения дат в MySQL.

Что-нибудь правда-ложь

Используйте: BIT(1) (только для MySQL 8.) В противном случае используйте BOOLEAN(1).

BOOLEAN на самом деле просто псевдоним TINYINT(1), который на самом деле хранит от 0 до 255 (не совсем правда / ложь, не так ли?).

Все, что вы хотите вызвать `SUM ()`, `MAX ()` или аналогичные функции на

Использование: INT(11).

VARCHAR или другие типы полей не будут работать с функциями SUM() и т. д.

Все, что превышает 1000 символов

Использование: ТЕКСТ.

Максимальный лимит - 65 535.

Что-нибудь более 65 535 символов

Использование: MEDIUMTEXT.

Максимальный лимит составляет 16 777 215.

Что-нибудь более 16 777 215 символов

Использование: LONGTEXT.

Максимальный лимит составляет 4 294 967 295.

Имя Фамилия

Использование: VARCHAR(255).

Символы UTF-8 могут занимать три символа на видимый символ, а в некоторых культурах не различают имя и фамилию. Кроме того, у культур могут быть разногласия по поводу того, какое имя - первый, а какое - последний. Вы должны назвать эти поля Person.GivenName и Person.FamilyName.

Адрес электронной почты

Использование: VARCHAR(256).

Определение пути электронной почты установлено в RFC821 в 1982 году. Максимальный лимит электронной почты был установлен RFC2821 в 2001 году, и эти ограничения оставались неизменными RFC5321 в 2008 году (см. Раздел: 4.5.3.1. Ограничения и минимумы размера.) RFC3696, опубликованный в 2004 году, ошибочно цитирует ограничение адреса электронной почты как символы 320, но это был RFC «только для информации», который явно «не определяет никаких стандартов» в соответствии с его вступлением, поэтому не обращайте на него внимания.

Телефон

Использование: VARCHAR(255).

Вы никогда не знаете, когда номер телефона будет иметь вид «1800 ...», «1-800» или «1- (800)», или будет ли он заканчиваться на «доб. 42» или « спроси Сьюзан ".

Почтовый индекс

Использование: VARCHAR(10).

Вы получите такие данные, как 12345 или 12345-6789. Используйте проверку, чтобы очистить этот ввод.

URL

Использование: VARCHAR(2000).

Официальные стандарты поддерживают гораздо более длинные URL-адреса, но немногие современные браузеры поддерживают URL-адреса более 2000 символов. См. этот SO-ответ: какова максимальная длина URL-адреса в разных браузерах?

Цена

Использование: DECIMAL(11,2).

Достигается 11.