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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

| 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       

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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