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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

  • VARCHAR (254) для писем
  • TIMESTAMP для дат, создания или изменений отслеживания
  • DECIMAL (3,2) (без знака) для 5-звездочного рейтингового значения
  • VARCHAR (255) для имен файлов
  • TINYTEXT для описания

UPD: я собрал несколько общих полей в таблице: http://korinets.name/mysql-common-data-types.html

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Таблица чисел, где я отклоняюсь от этого. Я настроил его на пять столбцов с именем NameID, Phone #, CountryCode, Extension и PhoneType. Я уже обсуждал NameID. Телефон # является 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]). Это гарантирует, что только то, что я хочу, попадает в базу данных, и данные остаются очень последовательными. Расширение и коды стран я назвал nullable smallints, но это может быть varchar, если вы этого захотите. PhoneType - varchar (20) и не имеет значения NULL.

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