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

голоса
96

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

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

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

Задан 10/12/2008 в 01:48
источник пользователем
На других языках...                            


5 ответов

голоса
59

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

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

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

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

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

Ответил 10/12/2008 в 01:57
источник пользователем

голоса
25

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

| 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       
Ответил 29/12/2009 в 00:40
источник пользователем

голоса
14

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

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

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

Ответил 10/12/2008 в 02:01
источник пользователем

голоса
8

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

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

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

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

Ответил 10/12/2008 в 02:08
источник пользователем

голоса
1

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

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

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

В таблице Числа где я отклониться от этого. Я поставил его на пять столбцов меченых NameID, телефон #, COUNTRYCODE, расширение и PHONETYPE. Я уже обсуждал NameID. Телефон # являются VARCHAR (12) с проверочным ограничением ищет что-то вроде этого: ПРОВЕРКИ (телефон # как «[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) и не обнуляемым.

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

Ответил 26/02/2010 в 06:13
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more