Common data types (MySQL) / Рекомендуемые типы данных MySQL
Янв 05
web dev. bilingual, mysql, типы данных 3 Comments
Довольно часто при проектировании очередной базы данных, мне приходится заново ‘придумывать’ какого типа должен быть тот или иной столбец. Например, идентификатор ряда (primary key) – какой тип, INTEGER или INT(8)? А, кого типа задать столбец для записи пути файла? Я не нашел сводных таблиц в Гугле или Яндексе (за исключением вопроса на stackoverflow.com), поэтому решил составить свою. Надеюсь она будет полезна не только мне.
Inspired by a stackoverflow.com question. any comments or additions are more than welcome. / Любые комментарии и дополнения по этой теме приветствуются.
| Column / Столбец | Data type / Тип данных | Comment / Комментарий |
|---|---|---|
| id / идентификатор | INTEGER | AUTO_INCREMENT, UNSIGNED |
| title / заголовок | VARCHAR(255) | |
| description / описание | TINYTEXT | often may not be enough, use TEXT instead / часто недостаточен из-за ограничений, можно использовать TEXT |
| post body / текст поста | TEXT | |
| VARCHAR(80) | ||
| salt (x – you decide) |
CHAR(X) | randomly generated string, usually of fixed length / строка случайных символов, как правило фиксированной длины |
| digest (md5) | CHAR(32) | |
| phone / телефон | VARCHAR(20) | |
| file path / файл (путь) | VARCHAR(255) | |
| 5-star rating / рейтинг | DECIMAL(3,2) | UNSIGNED |
| price / цена | DECIMAL(7,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 / статус | BOOL / TINYINT(1) | 1 – published, 0 – unpublished, … |
UPD: INT(11) in id is changed into INTEGER because ZEROFILL is not used. / Я изменил INT(11) в поле id на INTEGER, так как не использую ZEROFILL
UPD2: * по мнению одного моего товарища (@RuSHA), вместо записи в строку лучше пользоваться отдельной таблицей – выборка через LIKE может оказаться куда прожорливей чем грамотно построенный JOIN.
UPD3: поля varchar(n) можно заменить на аналогичные char(n) – это займет больше места, однако, из-за фиксированной длины char скорость выдачи данных увеличится.
Меня зовут Максим Коринец и с 1996 года вся моя работа и большинство мыслей связаны с интернетом. Сейчас я разрабатываю веб-приложения на Zend Framework
Июн 17, 2010 @ 12:12:50
Пару раз «накололся» с TINYTEXT- ограничение по длине 255 (2^8 – 1)
и TINYINT (аналогично – максимум 255).
В некоторых случаях использование char(80) более оправдано, нежели varchar (80). Будет занимать больше места, зато время на выборку сократится (если заведомо известно, что одна запись занимает Х байт, то 100-я запись начнется с 99*X+1 байта).. Правда, пару лет назад проверял.. но, думаю, и сейчас работает
ps. все хорошо в разумных пределах..
Июн 17, 2010 @ 14:04:06
@Levik, сам недавно «накололся» с ограничением TINYTEXT. Заменил на TEXT. Также соглашусь что char быстрее varchar хоть и жирнее. Однако, как исправить таблицу, если мы хотим дать рекомендации для наиболее распространенных случаев? Можно, например, всегда рекомендовать char, если быть уверенным, что у разработчика объем БД не проблема.
Пожалуй, пока я добавлю в комментариях эти моменты.
Июн 19, 2010 @ 14:43:12
спасибо:) дописал price