Продолжаем важную часть разработки интернет-проекта slang.ru - планирование.

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

Строим соответствующую таблицу связей:

create table tbl_dic_word
(
 dw_id      int unsigned not null auto_increment primary key,
 dw_dic     smallint unsigned not null,
 dw_word    int unsigned not null,
 dw_desc    text not null default '',
 dw_enable  enum('Y','N') not null default 'Y'
);

dw_dic и dw_word - это идентификаторы словаря и слова, а dw_desc - описание данного слова в данном словаре.

Ну вот, у нас уже получилась вполне жизнеспособная база данных. Давайте в нее загрузим первые данные:

insert into tbl_dic(d_name) values('Словарь тестов');
insert into tbl_word(w_word) values('Слово');
insert into tbl_dic_word(dw_dic, dw_word, dw_desc) values(1,1,'слово - это Слово!');

Замечательно - у нас уже есть первый словарь!

Самое время вспомнить о людях. О тех людях, которые будут создавать словари и будут управлять ими. Задумка такова, что каждый желающий может сделать для себя любое количество словарей, каждый из которых может быть private или public. Первый (private) доступен для редактирования и добавления только автору, а второй (public) - всем желающим.

Поразмыслив над задумкой я пришел к следующим атрибутам доступа к словарям (эти атрибуты устанавливает автор словаря):

1 - просмотр словаря
2 - добавление описания
4 - изменение описания (чужого)
8 - удаление описания (чужого)
16 - добавление слова
32 - удаление слова (чужого)
64 - reserved
128 - контроль доступа

Разумеется, свои описания пользователь может редактировать и удалять.

Цифры - это код атрибута (об этом чуть ниже).

Пока понятно о чем я пишу? Если не понятно - задавайте вопросы на форуме.

Итак, нам требуется создать таблицу пользователей, связать ее с таблицей словарей и добавить атрибуты доступа в таблицу словарей.

create table tbl_user
(
 u_id      smallint unsigned not null auto_increment primary key,
 u_login   varchar(20) not null default '',
 u_pass    varchar(32) not null default '',
 u_fname   varchar(100) not null default '',
 u_lname   varchar(100) not null default '',
 u_semail  varchar(100) not null default '',
 u_pemail  varchar(100) not null default '',
 u_copi varchar(20) not null default '',
 u_text    text not null default '',
 u_enable  enum('Y','N') not null default 'Y'
);

Поясню некоторые поля:
u_pass - пароль, который будет храниться в хеше MD5, поэтому поле ровно 32 знака;
u_fname, l_name - имя и фамилия;
u_semail и u_pemail - это технический/секретный и публичный email-адреса;
u_copi - ну, это понятно: COPi-номер или COPi-имя в системе COPi.ru;
u_text - свободная информация о пользователе в текстовом формате;

Теперь давайте свяжем таблицу словарей с таблицей пользователей. Если мы просто добавим к таблице tbl_dic поле "автор", то этого уже будет достаточно. Но в этом случае хозяином словаря может быть только один человек. А если над словарем работает группа людей? Конечно, эта группа может зарегистрировать специального пользователя (одного на всех) и им пользоваться, но как тогда быть с журналом изменений? А как раздать на один словарь разные права разным пользователям? Поэтому я предлагаю все же создать отдельную таблицу, связывающую словари с пользователями и в ней определять права доступа к словарю.

create table tbl_user_dic
(
 ud_id      int unsigned not null auto_increment primary key,
 ud_user    smallint unsigned not null,
 ud_dic     smallint unsigned not null,
 ud_rights  tinyint unsigned not null default 1,
 ud_enable  enum('Y','N') not null default 'Y'
);

ud_rights - это поле для записи атрибутов доступа к словарю.

Поскольку мы уложились в 8 атрибутов доступа, нам будет достаточно целого числа от 0 до 256 (tinyint) для записи прав. Записывать мы их будем в двоичном виде, где каждый разряд отвечает за свой артибут доступа. Отсюда и такая странная, на первый взгляд, система нумерации атрибутов:

00000001 - 1 - просмотр словаря
00000010 - 2 - добавление описания
00000100 - 4 - изменение описания (чужого)
00001000 - 8 - удаление описания (чужого)
00010000 - 16 - добавление слова
00100000 - 32 - удаление слова (чужого)
01000000 - 64 - reserved
10000000 - 128 - контроль доступа

Идея понятна? Сложив любую комбинацию атрибутов, мы всегда получим уникальное число, отражающее права пользователя в данном словаре.

Примеры:
1 (00000001) - право на просмотр словаря;
49 (01100001) - право на просмотр, добавление и удаление слов.
255 (11111111) - все права

Примечание: права доступа в процессе развития проекта вполне могут изменяться - сокращаться, добавляться, изменяться.

Ну что, давайте добавим в базу данных пользователя и свяжем его с нашим первым словарем?

Добавляем пользователя:

insert into tbl_user(u_login, u_pass, u_fname, u_lname, u_semail, u_copi, u_text)
values('atos',md5('MyPassword'),'Руслан','Курепин',
'atos@21.ru','21', 'разработчик сайта slang.ru');

Обратите внимание, в поле u_pass будет записан хеш пароля: "48503dfd58720bd5ff35c102065a52d7"

Добавляем связь со словарем:

insert into tbl_user_dic(ud_user, ud_dic, ud_rights) values(1,1,255);

Готово. Теперь в нашей базе есть связка: слово -> словарь -> пользователь -> права доступа;

Мы уже неплохо продвинулись. Идем дальше!





[шаг назад] [печатать] [в начало сайта]