Типы полей в MySQL?

Question

[Artqookie]

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

• user_id
  
• user_name
  
• user_pass
  
• user_invite
  
• user_reg_flag
  
• user_mail
  
• user_course
  

Comments

[niko83]

продумывайте вопрос, уточняйте какие именно данные в каких полях вы собираетесь хранить. Например что вы хотите хранить в user_course я не догадался, или какой фаг в user_reg_flag, булевое значение? user_invite — это (bool) был ли пользователь по приглашению, или ID приглашающего пользователя… и т. д.

[Artqookie]

user_invite — инвайт генерируется автоматом и представляет собой набор символов: букв и цифр
user_reg_flag — флажок: 0 — не зарегистрирован, 1 — зарегистрирован
user_course — курс на котором учится студент :-) От 1 до 8 (включая магистров и аспирантов)

Answer 1

[L0NGMAN]

CREATE TABLE `users` (
`user_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_name` char(50) NOT NULL DEFAULT '',
`user_pass` char(32) NOT NULL DEFAULT '',
`user_mail` char(50) NOT NULL DEFAULT '',
`user_invite` tinyint(1) NOT NULL DEFAULT 0,
`user_created` TIMESTAMP DEFAULT '0000-00-00 00:00:00' NOT NULL,
`user_updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`user_id`),
UNIQUE KEY (`user_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Comments

[Artqookie]

Спасибо.

[niko83]

" `user_mail` char(50) и user_name` char(50) "
CHAR а не VARCHAR — вы уверены? можете обосновать?

[Вячеслав Плиско]

вот только MyISAM стоит использовать в случае FULL TEXT, а для остального InnoDB предпочтительнее, он даёт транзакции, внешние ключи и главное блокировку на уровне строки, а не всей таблицы.

[L0NGMAN]

Если исползовать CHAR в место VARCHAR, то ROW_FORMAT таблицы будет фиксированным. А в манах говорится что фиксированные таблицы обновляется и работает быстрее.

[niko83]

всё верно, но и занимает char(50) всегда 50 байт, даже тогда когда мы туда сохраняем пустую строку.

[L0NGMAN]

ИМХО для таблицы юзеров это не важно, главное быстродействие.

Answer 2

[Владимир Чернышев]

Под name использовать 25 в случае utf-8 имхо не самая лучшая идея, даже если ограничиться русским, на мыло 50 тоже может не хватить в извращенных случаях, но соответствующих rfc (домены.рф например :) ). Да и вообще никакого оверхеда между varchar(1) и varchar(256) нет, смысла экономить не вижу, если в требованиях есть ограничения, то проверять их в приложении и именно на количество символов, а не байт (для php — mb_strlen(), а не strlen() ).

Comments

[niko83]

согласен, принимаю. Тогда уже для `pass` наверное будет правильней CHAR(32), 1-ин байт экономии, так как пароль будет всегда и всегда 32 символа

[Владимир Чернышев]

Про pass я как-то забыл, хотя у самого всегда char :) Правда не 32, а 40 (sha1, а не md5 )

Answer 3

[niko83]

CREATE TABLE `users` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(25) NOT NULL DEFAULT '',
`pass` varchar(32) NOT NULL DEFAULT '',
`mail` varchar(50) NOT NULL DEFAULT '',
`invite` tinyint(1) NOT NULL DEFAULT 0,
`created` TIMESTAMP DEFAULT '0000-00-00 00:00:00' NOT NULL,
`updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Answer 4

[Chvanikoff]

Вообще, если сразу думать о хорошей архитектуре, то это не одна таблица должна быть.

Таблица1: ид, логин, пароль
Таблица2: данные о пользователе
Значение поля инвайт я не понял, но если имеется в виду «реферральная программа», или ее подобие — тоже отдельная таблица с данными «ид пользователя», «реферрер»
и вместо user_reg_flag сделать таблицу ролей пользователя в системе (у вас же еще, скорее всего, администратор будет?) — для начала «login» и «admin» и связать через связывающую таблицу пользователей с ролями, чтобы каждый мог иметь несколько. Тогда при подтверждении регистрации, например, добавляем юзеру роль«login», если хотим забанить (запретить вход) — убираем ее.

Если интересно — могу написать структуру этих таблиц.

ЗЫ: что касается собственно сабжа — не вижу смысла в оптимизации полей без оптимизации структуры БД.

Comments

[Artqookie]

Попробую сам. Благодарю за развернутый совет.

[Chvanikoff]

И не забудьте — тут будет связывание таблиц через внешние ключи (в основном на ID пользователя из основной таблицы), поэтому использовать нужно InnoDB.

[Max B]

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

[Chvanikoff]

И то верно… :)
проектирование баз данных
нормальная форма

Answer 5

[SwampRunner]

id — int 10 unsigned
name — varchar 25
pass — varchar 32 (после md5)
email — varchar 50

если нужен bool, то tinyint 1

Answer 6

[Max B]

В sqlyog есть замечательный анализатор таблиц. Создаете таблицу бездумно, наполняете ее данные, затем анализируйте и sqlyog предлагает вам оптимальные типы полей. От необходимости разбираться с СУБД не избавит, но может краткосрочно решить вашу проблему.

Comments

[niko83]

да верно в MySQL есть механизм такого рода, PROCEDURE ANALYSE() dev.mysql.com/doc/refman/5.0/en/procedure-analyse.html

Answer 7

[charon]

в общем случае: использовать фиксированный формат (char вместо varchar) минимально необходимой длины. Также можно учесть особенности архитектуры (32 -битный сервер: айди — целое беззнаковое размером 32 бита).

Answer 8

[mitnlag]

Я бы сказал, что хабр — не место для решения домашних задачек.