Базы данных « Как организовать хранение данных о пользователях?
Конечно, я хочу иметь возможность в любое время добавлять какого рода угодные поля, а также блокировать их изменения и делать "прочие клёвые штуки".
upd: Имею ввиду интересы, любимые книги, город, где живет, размер титек и пр.
З.Ы.: Повторюсь, что "прочие клёвые штуки" - это, своего рода, дисперсия того, чтобы вы хотели получить у Себя на сайте ;)
updEnd: Всем спасибо, ничего нового не узнал, думал есть решения изящнее. RayZ, разумеется, отдельное спасибо за философию и дедуктивный взгляд на проблему.
1 ответов
Опять, по традиции, давайте поразмышляем на эту тему.
В основном при проектировании учитываются практически все возможности будущей системы, однако расширения оказываются неизбежны и данный вопрос встает ребром - что делать и в какой именно таблице хранить данные.
При проектировании одной такой большой базы, с участием пользователей в системе, методом проб и ошибок пришел к одному выводу: данные лучше всего группировать по мере их использования при работе.
Рассмотрим простой пример, очень популярный в наше время - некая абстрактная социальная сеть. И сразу же попытаемся разгруппировать данные:
Пользователи (users) - Информация о пользователе, которая нужна для авторизации
Идентификатор (user_id)
Имя пользователя/Логин (user_name)
Пароль/Криптованный пароль (user_pass)
Дата регистрации (user_reg_date)
Дата время последней авторизации (user_login_date)
Настройки профиля пользователя (user_profile) - Информация расширяющая данные о пользователе, раскрывающая его душу ;)
Идентификатор пользователя (user_id)
День рождения (profile_birthday)
Пол (profile_gender)
Обтекаемость в аэродинамической трубе (profile_streamlining)
... и так далее
Настройки сайта для пользователей (user_settings) - Информация относящаяся непостредственно к способам вывода информации для пользователей
Идентификатор пользователя (user_id)
Количество результатов на странице (settings_res_per_page)
Выводить абстрактный блок информации на странице пользователя (settings_show_info_block)
... и так далее
Что из написанного выше следует?
Разбив данную информацию на 3 таблицы, мы получаем точное представление о ее качестве. При разработке модулей (контроллеров, библиотек, функций /ненужное зачеркнуть/) не получится путаницы. Что именно я хотел донести? - Разделяй и властвуй! ;) зерна в одну корзинку, чечевицу - в другую. Маркировка таблиц и полей таблиц в соответствии с типом информации заметно ускоряет разработку, упрощает проектирование.
Надеюсь, что понятно донес идею.
update
Перечитал вопрос, у меня еще один ответ возник.
Слышали о таблицах - конструкторах свойств?
Очень похожий пример используется в Яндекс-Маркет. То есть существует некая таблица непосредственно обозначающая некую единицу. Так же существует таблица, содержащая информацию о его свойствах, даже не свойствах, а индексах свойств, и его значений. И, соответственно, ко всему этому прилагаются таблицы, которые обозначают множества свойств, их значения по умолчанию, типизация значений. Все это собирается воедино, к сожалению, не одним запросом, однако предоставляет возможность как пользователям - выбирать наборы свойств объекта (еденицы), так и администраторам - конфигурировать практически любые свойства в пределах установленных возможностей. :)
есть предложение хранить параметры юзеров в таблице типа
user_profile
user_id , key, value
в этом случаем мы можем добавить любой дополнительный параметр для юзера , да хоть он сам его и создаст для себя ) .
и сразу на всикидку )
$name = $user->param(name); #getter
$user->param(name,"Vasya"); #setter
а на счет клевые штуки ) я думаю что какой нибудь парень добавив у себя ))) что то типа "Сколько у меня было девушек )" подключит других парней которые тоже поставят себе такой же параметр по ссылке или еще как то )
тоесть фантазия уже ограничится фантазией пользователя для своей анкеты ) сделать лимит параметров и отключать ограничение за смс )
вот как то так )
Создаем основную таблицу пользователей
CREATE TABLE user(
user_id number constraint user#user_id#pk primary key,
passw varchar2(255 char),
STATUS number, -- e.g.: 0 - active, 1- passive
reg_date date,
last_auth date
);
Далее таблицы с произовльными аттрибутами, кои можем добавлять когда угодно не используюя DDL операторов
CREATE TABLE user_attr(
ua_id number constraint user_attr#ua_id#pk primary key,
user_id number,
attr_name varchar2(255 char),
attr_val varchar2(255 char)
);
ALTER TABLE user_attr
ADD constraint user_attr#user_id#fk
FOREIGN KEY (user_id) REFERENCES user(user_id);
Теперь можно добавлять сколько угодно аттрибутов для пользователя. Правда все будут типа VARCHAR2
Смотря что ты хочешь там хранить. Но, думаю, минимум это
CREATE TABLE IF NOT EXISTS `users` (
`uid` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) collate utf8_unicode_ci NOT NULL DEFAULT '',
`type` int(11) NOT NULL DEFAULT '0',
`users` int(11) NOT NULL DEFAULT '0',
`uname` varchar(255) collate utf8_unicode_ci NOT NULL DEFAULT '',
`email` varchar(255) collate utf8_unicode_ci NOT NULL DEFAULT '',
`pass` varchar(100) collate utf8_unicode_ci NOT NULL DEFAULT '',
`date_reg` varchar(100) collate utf8_unicode_ci NOT NULL DEFAULT '0000-00-00 00:00:00',
`valcode` varchar(35) collate utf8_unicode_ci NOT NULL DEFAULT '',
`state` int(11) NOT NULL DEFAULT '3',
PRIMARY KEY (`uid`),
UNIQUE KEY `i_users_uname` (`uname`),
KEY `i_users_type` (`type`),
KEY `i_users_name` (`name`),
KEY `i_users_email` (`email`),
KEY `i_users_state` (`state`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
где, type - 0\1 - группа\юзер
users - кво юзеров в группе
pass - md5 пароля
valcode - код валидаци пользователя, если активирована валидация е-мейла
state - типа состояние пользователя (Неактивный\Не проверенный\Активный\Ожидающий одобрения\Удаленный и т.п.)