Common data types (MySQL) / Рекомендуемые типы данных 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
email VARCHAR(254)
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 скорость выдачи данных увеличится.

3 Comments (+add yours?)

  1. Levik
    Июн 17, 2010 @ 12:12:50

    Пару раз «накололся» с TINYTEXT- ограничение по длине 255 (2^8 – 1)
    и TINYINT (аналогично – максимум 255).

    В некоторых случаях использование char(80) более оправдано, нежели varchar (80). Будет занимать больше места, зато время на выборку сократится (если заведомо известно, что одна запись занимает Х байт, то 100-я запись начнется с 99*X+1 байта).. Правда, пару лет назад проверял.. но, думаю, и сейчас работает :)

    ps. все хорошо в разумных пределах.. :)

  2. yentsun
    Июн 17, 2010 @ 14:04:06

    @Levik, сам недавно «накололся» с ограничением TINYTEXT. Заменил на TEXT. Также соглашусь что char быстрее varchar хоть и жирнее. Однако, как исправить таблицу, если мы хотим дать рекомендации для наиболее распространенных случаев? Можно, например, всегда рекомендовать char, если быть уверенным, что у разработчика объем БД не проблема.

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

  3. yentsun
    Июн 19, 2010 @ 14:43:12

    спасибо:) дописал price

Высказаться

Spam protection by WP Captcha-Free