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

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

Поскольку я уверен, что другие люди, вероятно, найдут это полезным, я не хочу ограничивать свой вопрос только полями, которые я упомянул выше.

Какие типы данных подходят для общих полей базы данных? Поля вроде номера телефона, электронной почты и адреса?

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

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

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

• INT (11) для всего, что является идентификатором или ссылается на другой идентификатор
• DATETIME для отметок времени
• 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, который является внешним ключом для всего, кроме таблицы 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.

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