Разработка интернет-приложения для организации электронной доски объявлений (стр. 2 из 6)
login – логин пользователя, тип поля text.
password – 32-х символьный хэш-код пароля пользователя, тип поля text.
contact – контактная информация пользователя, тип поля text.
access – права доступа, тип поля smallint. 0 - администратор, 1 – пользователь, 2 – модератор.
5. Таблица MESSAGES.
Предназначена для хранения текста объявлений и их параметров, заданных отправителем.
| id | topic_id | user_id | action_id | time | time_live | text |
id – идентификатор объявления, тип поля int, ключевое, auto_increment, index.
topic_id – значение идентификатора подраздела каталога, тип поля int, index.
user_id – значение идентификатора отправителя (пользователя), тип поля int.
action_id – значение идентификатора типа объявления, тип поля smallint.
time – дата написания объявления, тип поля text.
time_live – время удаления объявления в UNIX-формате, тип поля bigint.
text – текст объявления, тип поля text.
6. Таблица MAIL.
Содержит адреса и параметры, использующиеся для почтовой рассылки объявлений.
| id | user_id | activation | time |
id – идентификатор записи, тип поля int, ключевое, auto_increment, index.
user_id – значение идентификатора отправителя (пользователя), тип поля int.
email – почтовый адрес подписчика на рассылку, тип поля text.
activation – код для активации, тип поля text. После подтверждения активации значение поля равно 1. При временном выключении рассылки значение поля 0.
time – содержит значение времени в UNIX-формате, по истечению которого не активированная запись будет автоматически удалена из таблицы, тип поля bigint.
7. Таблица MAILSUB.
Описывает связь между подразделами и адресами подписчиков, которая используется для почтовой рассылки объявлений.
| mail_id | topic_id |
mail_id – значение идентификатора записи подписчика в таблице MAIL, тип поля int, index.
topic_id – значение идентификатора подраздела, на который оформлена подписка, тип поля int, index.
8. Таблица SESSIONS.
Содержит значения идентификаторов сессий авторизованных пользователей, используется для реализации механизма безопасной аутентификации.
| user_id | sid | time |
user_id – значение идентификатора пользователя в таблице USERS, тип поля int.
sid – идентификатор сессии авторизованного пользователя, тип поля text.
time – значение времени в UNIX-формате, по истечению которого не продленная сессия будет автоматически удалена из таблицы, тип поля bigint.
Связи между полями таблиц приведены на рис. 2.1 структурной схемы данных. Ключевые поля-идентификаторы помечены знаком “*”, типы используемых связей: “один ко многим” и “один к одному”.
Рис. 2.1 - Схема данных
3. Разработка схемы программы
Рассмотрим основные задачи и требования, предъявляемые к разрабатываемому приложению на уровне организации WEB-интерфейса:
1) интерфейс отображение разделов каталога и объявлений,
2) интерфейс аккаунта пользователя,
3) интерфейс аккаунта модератора,
4) интерфейс аккаунта администратора,
5) интерфейс подписки на почтовую рассылку,
6) интерфейс авторизации и регистрации пользователей.
На функциональном уровне:
1) первоначальная инсталляция приложения на сервере,
2) соединение с БД MySQL,
3) инициализация основных параметров каталога,
4) проверка на корректность значений переменных, принимаемых от пользователя,
5) вывод разделов и подразделов каталога, а также объявлений,
6) регистрация новых пользователей,
7) авторизация пользователей,
8) аутентификация пользователей с помощью механизма сессий и проверка прав доступа,
9) добавление, редактирование и удаление объявлений,
10) организация механизма почтовой подписки с запросом подтверждающего кода,
11) подписка на подразделы каталога, активация, деактивация и удаление адреса из рассылки,
12) рассылка объявлений на почтовые адреса подписчиков,
13) редактирование основных параметров приложения,
14) добавление и удаление пользователей,
15) установка и снятие прав доступа с пользователей,
16) автоматическое удаление объявлений по истечению срока жизни, удаление не продлённых пользовательских сессий, удаление не активированных адресов почтовой рассылки.
На рис. 3.1 показана общая схема приложения и взаимодействие между его основными частями.
Рис. 3.1 - Функциональная структура программы
Таким образом, проект целесообразно реализовать в виде нескольких функциональных модулей, каждый из которых будет выполнять определённую задачу:
1) модуль инсталляции (с отображением интерфейса),
2) модуль соединения с БД MySQL,
3) модуль отображения разделов каталога и объявлений (с отображением интерфейса),
4) модуль регистрации новых пользователей (с отображением интерфейса),
5) модуль авторизации пользователей (с отображением интерфейса),
6) модуль аутентификации пользователей, основанном на механизме сессий,
7) модуль реализации аккаунта пользователя (с отображением интерфейса),
8) модуль реализации аккаунта администратора (с отображением интерфейса),
9) модуль реализации аккаунта модератора (с отображением интерфейса),
10) модуль реализации аккаунта подписки на почтовую рассылку (с отображением интерфейса).
4. Разработка алгоритмов
1) Алгоритм инсталляции.
Инсталляция подразумевает первоначальную установку приложения на интернет-сервер и создание аккаунта администратора. После инсталляции администратор переходит в свой аккаунт и добавляет разделы и подразделы в основной каталог.
Модуль-инсталлятор выполняет следующие действия:
а) создает новую БД или удаляет все таблицы в текущей БД, использующиеся приложением, если они уже были созданы;
в) создает таблицы с указанием всех необходимых полей и типов;
г) добавляет записи со значением базовых параметров в статические таблицы ACTION и OPTIONS.
г) запрашивает логин и пароль администратора, добавляет запись в таблицу USERS и установить права администратора.
2) Алгоритм отображения разделов и подразделов.
Для отображения списка разделов необходимо послать запрос на получение всех значений поля name из таблицы SUBJECT, где значение идентификатора раздела каталога topic = 0, и вывести результат на экран.
Для отображения списка подразделов используется точно такой же метод, только значение идентификатора раздела каталога topic сравнивается с текущим идентификатором раздела.
Для того чтобы записи сортировались в алфавитном порядке, все запросы дополняются директивой «ORDER BY name ASC». Если в текущем подразделе каталога присутствуют объявления нескольких типов, выводится вспомогательный список-фильтр с перечислением найденных типов, тогда пользователь может выбирать тот или иной тип объявлений, который должен выводиться на всех разделах и подразделах каталога.
3) Алгоритм отображения объявлений с применением фильтра на тип объявлений.
Для отображения объявлений берутся все значения полей таблицы MESSAGES, в которой значение поля topic_id совпадает со значением текущего идентификатора раздела каталога. Поскольку при отображении объявлений необходимо выводить ещё и контактную информацию об отправителе, а также тип объявления, в запрос вводятся дополнительные условия: значение поля user_id таблицы MESSAGES должно совпадать со значением идентификатора пользователя id таблицы USERS, а значение поля action_id – со значением поля id таблицы перечисления типов объявлений ACTION. Если пользователь применил фильтр на тип объявлений, запрос дополняется ещё одним условием: значение поля action_id должно соответствовать значению фильтра. Сортировка записей производится по полю id в порядке убывания, в результате чего вверху WEB-страницы каталога отображаются последние добавленные объявления.
4) Алгоритм ограничения числа объявлений, выводимых на одной WEB-странице.
Поскольку число объявлений, удовлетворяющих вышеприведённому запросу может быть слишком велико, для того чтобы не перегружать выводимые WEB-страницы используется алгоритм ограничения числа объявлений и формирование так называемой линейки – ссылок на страницы, содержащие результаты запроса. Для этого с помощью директивы COUNT предварительно подсчитывается количество строк в результирующем запросе, причём приложение запрашивает у БД именно число строк в нужном запросе, а не результат запроса, тем самым экономя время обмена данными и трафик (в случае если БД находится на другом удалённом сервере). По полученному значению определяется, нужно ли формировать линейку или нет. Если нужно, запрос дополняется директивой LIMIT с перечислением диапазона выводимых значений в результирующем запросе. Диапазон представляет собой некоторое начальное значение указателя на «окно» и максимальный размер этого «окна». Таким образом, результат запроса делится на «окна» и не перегружает выводимые страницы. Пользователь может выбирать для просмотра то или иное «окно», при этом само содержание запроса не изменяется, меняются лишь границы диапазона.
5) Алгоритм передачи значения фильтра при переходах по ссылкам каталога.
Включив фильтр на тип объявлений, пользователь может перейти с текущей страницы каталога на какую-либо другую, причём во время таких переходов приложение должно «знать», что фильтр был включен. Самый оптимальный способ для сохранения значения фильтра в случае программирования на языке PHP – это использование механизма сессий.