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

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

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

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

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

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

, Как другие сказали, номера телефона и zip/индексы не являются на самом деле числовыми значениями, они - строки, содержащие цифры 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.

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