Краткое содержание предыдущих серий
И так, имея скромный набор требований, описанный в первой статье, перейдем непосредственно к разработке.
Когда я приступаю к разработке нового приложения или сайта, и уже более или менее понятно с какими сущностями придется работать и какие данные хранить, лично я, предпочитаю нарисовать схему базы данных, которая в будущем будет хранить всю информацию приложения. Такая схема позволит более наглядно представить все объекты, разрабатываемого приложения и взаимосвязи между ними. Для рисования таких схем, можно воспользоваться любым инструментом, начиная от листа бумаги и карандаша, заканчивая специализированным ПО, типа MS VISIO. Однако, я предпочитаю программное обеспечение, специально предназначенное для этих целей. Довольно давно, я пользуюсь Mysql Workbench, для проектирования баз данных Mysql, подробнее узнать про эту программу и скачать ее, можно тут.
Примерно за 40 минут работы, у меня получилась вот такая вот схема БД.
Сейчас постараюсь подробно рассказать про назначение каждой таблицы и каждого столбца.
И так поехали!
User — предназначена для хранения данных о зарегистрированных пользователях (на первом этапе разработки, наша цмска будет однопользовательской — т.е. добавлять контент сможет любой пользователь прошедший авторизацию, в связи с этим, на первом этапе не будет возможности регистрироваться новым пользователям).
- userId — идентификатор пользователя;
- name — имя пользователя;
- email — email пользователя;
- password — пароль пользователя;
- creationDate — дата регистрации пользователя (пока система однопользовательская — особого смысла в этом поле нет);
- status — 0 — пользователь активен 1 — пользователь заблокирован;
- accessLevel — 0 — простой пользователь 1 — администратор (может управлять контентом и совершать административные действия)
System — таблица для хранения всех системных параметров.
- systemId — идентификатор записи
- siteUrl — основной url сайта
- siteInfo— информация о сайте
- siteDescription — описание сайта
- ownerInfo — информация о владельце
- ownerEmail — email администратора сайта
- userId — пользователь создавший настройку (в однопользовательской работе на учитывается)
Content — данная таблица будет содержать все записи (посты), страницы и все остальное наполнение нашего движка.
- contentId — идентификатор записи
- title — заголовок записи
- alias — строка Url данного записи
- content — содержимое поста
- status — 0 — черновик, 1 — опубликовано
- keywords — ключевые слова для записи (meta)
- description — описание записи (meta)
- createdBy — идентификатор пользователя создавшего запись
- creationDate — дата создания
- active — признак того что эта запись является самой последней (актуальной)
- canComment — разрешены ли комментарии для данной записи
- isPrivate — пост доступен только авторизованным пользователям (в версии 1 нашего движка это работать не будет)
- publishDate — дата публикации
- revision — номер версии записи
- contentParentId — идентификатор, изначально созданной записи
- revisionParentId — идентификатор, предыдущей ревизии
- contentType — тип контента 2 — запись (пост) 1 — страница
- modifyDate — дата изменения
- modifyBy — кем изменено
- commentCnt — количество комментариев
Comment — таблица хранит комментарии к постам и страницам (?).
- commentId — идентификатор комментария
- parentId — родительский комментарий (в первой версии движка мы его использовать скорее всего не будем)
- postId — идентификатор поста, к которому относится комментарий
- comment — текст комментария
- creationDate — дата создания комментария
- userName — имя пользователя, создавшего комментарий
- userEmail — email пользователя, создавшего комментарий
- userUrl — url пользователя, создавшего комментарий
- userIp — ip-адрес пользователя оставившего комментарий
- status — 0 — комментарий не подтвержден, 1 — комментарий одобрен, 2 — спам
Tag — таблица хранит тэги.
- tagId — идентификатор тэга
- tag — название тэга
TagContent- таблица предназначена для хранения отношения тегов и постов
- tagContentId — идентификатор контента
- contentId — идентификатор записи
- tagId — идентификатор тэга
Я думаю, что в процессе разработки, придется корректировать и дополнять эту схему, но для начала работы она вполне подойдет.
Если есть какие-то замечание или предложения — прошу высказываться в комментариях.
p.s. Названия движка, пока так и не выбрано — любые варианты приветствуются!
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!
Читайте еще:
Пропиши теги к записи.
И собственно зачем tagContentId если контент у тебя пока что только Post-ы? Или это тупо в коде планируешь прописывать?
ты говоришь про табличку «TagContent»??? Она как раз и предназначена для «привязки» тэгов к записи. У меня выработалась привычка (не знаю правильная или нет) в любой таблице — должен обязательно присутствовать первичный ключ, отсюда и появление столбца tagContentId. Завтра выложу обновленную версию схемы — там в табличке content есть признак «contentType».
изменил описание некоторых таблиц, чуть позже выложу новыю схему
хм… а почему выбран способ задание системных парпаметров таблицей в БД, а не конфиг файлом?
я сам новичек в пхп, будет интересно почитать про создание всё с нуля, спасибо)
имхо…параметры в таблице — проще редактировать, однако, написав кое какой функционал, я обнаружил (!) что эти самые параметры приходится считывать практически при каждом запросе. Если вынести параметры в файл — кол-во запросов сократится ровно на 1 ))) А это уже не плохо! Возможно, позже основные параметры будут именно в файлах.
Добрый день, а есть где-то более актуальная информация по модели базы данных для цмс? Я сейчас в процессе написания дипломной работы, делаю портал для работы с информацией в области медицины, и на данный момент проектирую базу данных. Понятно, что мне надо учитывать много деталей касаемых конкретно моего проекта, но общая модель мне бы сильно помогла.
Спасибо