Общая структура

Основываясь на анализе требований, мы решили использовать для хранения данных нашего приложения следующие таблицы:

• tbl_user хранит пользовательскую информацию, включая имя пользователя и пароль;
• tbl_post хранит информацию о записях блога:
  • title: необходимо, заголовок записи;
  • content: необходимо, содержимое записи в формате Markdown;
  • status: необходимо, статус записи. Может принимать значения:
    • 1: запись находится в черновом варианте и читателям не видна;
    • 2: запись опубликована;
    • 3: запись с истёкшим сроком действия: не публикуется в общем списке, но всё ещё доступна отдельно.
  • tags: опционально. Список разделённых запятой тэгов, относящих запись к той или иной категории;
• tbl_comment хранит информацию о комментариях. Каждый комментарий ассоциируется с некоторой записью и содержит следующие поля:
  • author: необходимо, имя автора;
  • email: необходимо, email автора;
  • url: опционально, адрес веб-сайта автора;
  • content: необходимо, текст комментария в текстовом формате;
  • status: необходимо, статус комментария, показывающий, утвержден ли комментарий (значение 2) или нет (значение 1);
• tbl_tag хранит информацию о тегах записей и их количестве. Используется для построения облака тегов. Таблица содержит следующие поля:
  • name: необходимо, уникальное имя тега;
  • frequency: необходимо, количество использований тега в записях.
• tbl_lookup хранит информацию о текстовых синонимах целочисленных данных (кодов). Коды используются при разработке, синонимы непосредственно показываются пользователям. К примеру, мы используем целое число 1 для обозначения чернового статуса записи и строку Черновик, которую мы показываем пользователям. Таблица содержит следующие поля:
  • name: текстовое представление данных, отображаемое пользователю;
  • code: целочисленное представление данных;
  • type: тип данных;
  • position: порядковый номер для данных одного типа.

Следующая диаграмма сущность-связь (ER) показывает структуру таблиц и связей между ними.

Информация: Мы называем все таблицы и их поля в нижнем регистре так как различные СУБД воспринимают регистр по-разному.

Также мы используем префикс tbl_. Сделано это по двум причинам. Во-первых, префикс позволяет хранить данные нескольких приложений в одной БД, что часто приходится делать в условиях виртуального хостинга. Во-вторых, использование префиксов уменьшает вероятность совпадения имён таблиц с зарезервированными ключевыми словами СУБД.

SQL, соответствующий ER-диаграмме выше, вы можете найти в демо-блоге. В установленной копии фреймворка они находятся в файле /wwwroot/yii/demos/blog/protected/data/schema.sqlite.sql.

Мы разделили разработку нашего приложения на несколько основных этапов:

• Этап 1: создание прототипа системы управления блогом. Он должен содержать большую часть требуемой функциональности;
• Этап 2: управление записями: создание, удаление, отображение записей списком, отображение отдельной записи;
• Этап 3: управление комментариями: создание, обновление, удаление, показ списком и утверждение комментариев к записям;
• Этап 4: реализация портлетов: меню пользователя, формы входа, облака тегов и недавних комментариев;
• Этап 5: финальная оптимизация и развертывание.