Хочется получить схему хранения данных для списка задач
-- минифорум
-- блог
-- комментарии к статьям на сайте
-- сервис "FAQ", "Вопрос-ответ"
-- гостевая книга.

Зачем? Для сайта часто хочется вставить одно, другое или третье, а плодить лишние таблицы и код, их поддерживающий не хочется.

предварительный список задач, которые должна поддерживать схема хранения данных

-- работать с авторизацией и без.

От минифорума потребуется 
-- создавать разделы, достаточно ветвистые по темам
-- выводить постранично все ответы в разделе
-- поиск по тексту сообщения, по индексу "цитируемого поста", по пользователю
-- "новые сообщения с последнего посещения"

От блога 
-- Создавать разделы
-- размещать комментарий в разделе
-- комментировать другие комментарии
-- поиск по тексту комментария, пользователю

гостевая - частный случай форума
FAQ - частный случай гостевой

придумалась такая схема таблицы (mysql)

Вероятно, здесь не хватает fulltext индекса для поля text, но я пока в раздумьях о выборе поискового движка.

при ближайшем рассмотрении - это обычное Adjacency List дерево

примерная дисциплина универсальной работы
Если пользователь авторизован - заполняется поле user, если юзер не авторизован или желает выглядеть по новому - заполняем поле username

Все поля, по которым возникает потребность искать - вынесены в отдельные поля. Все поля сообщения, которые достаточно только выводить - сериализуются в поле info. потеря скорости на этой операции не будет сильно сказываться, так как поля используются только для вывода информации и вывод на страницу идет постранично.

примерный алгоритм работы с "комментариями"
-- в комментарии присутствует> кроме юзера, текста и даты еще "цитируемый участок текста" и "цитируемый комментарий", соответственно, поля "quote" (сериализуется в info) и quote_id.

Для каждого "места подключения комментария" на странице заводится пустая строка в таблице forum_tree. Ее индекс и будет parent'ом для всех комментариев этой точки.

Для форума, гостевой книги, и т.д., также заводится "root"-овая строчка, от которой уже будем получать весь список тем форума. Индекс рутовой строки должен быть сохранен в конфигурации сайта.
Таким образом в одной таблице имеется возможность хранить довольно много форумов, блогов и прочих фенечек.

А! вопрос то я не задал   

У кого какие потребности к форумам, гостевым и прочим комментариям были? Ну там модерирование сообщений, еще что ?

Имхо извращение   

Вещь вроде faq вопрос ответ как правильо маленькая и легенькая таблица...

То что ты пытаешься сотворить , это большой не поворотливый монстр   

Какие преимущества держать все в одной таблице?

Есть какая то средняя грань... явное дело что для каждого сообщения отдельная таблица не нужна...

но и все в одну пихать не правильно!

Мне как-то попался faq с возможностью комментирования.   


Код, который управляет таблицей (вставка-удаление-список-поиск) сидит в одном месте и несложно портируется на нужные нужды. "модельный" интерфейс всех этих вещей imho, примерно одинаковый, хотя faq, возможно, немного более одинаковый чем другие. ;)

в faq, если его делать одной таблицей, достаточно пары полей - вопрос ответ. возможно еще дата, как привязка ко времени и способ изменить порядок  вывода. если вспомнить о пользователе, который задал вопрос и о пользователе, который ответил. то почти все поля моей таблицы удастся заполнить... Деревянность, разве что не очень нужна для faq/ но если бить его на разделы, то почему бы и нет...


Мне пока так не кажется. Во всяком случае, поиск и вывод информации достаточно шустрый. Какая-то потеря производительности имеет место быть при десериализации "комплексного" поля(info), но если не пихать туда очень большие данные и не требовать поиска по ним - то задержка незначительна.

Для поиска по тегам (как в этом форуме) придется, видимо, мастерить отдельную таблицу все равно. Хотя нужен ли поиск по введенным кем-то там тегам? Мне тут до сих пор не пригодился, а для "минифорума", как я его вижу, такое можно и не делать.

Вероятно, отдельная таблица нужна и для индексированного поиска. В поле text будет сидеть, как правило, html, а по нему как-то не очень интересно искать fulltext'ом. слишком много угловых скобок, так что в отдельной таблице - лишенный форматирования текст с адресом страницы...

ну а самое главное - форум и гостевая - "небольшие", то есть заботится об оптимальном расходовании памяти пока не приходится, и пара лишних полей в базе - не критична.
к тому-же, на мой взгляд, самые наполняемые разделы - комментарии и форум, а там все поля используются...


Это сообщение отредактировал(а) ksnk - 6.12.2010, 20:59

имхо таково, что по сути - это одинаковые вещи. а раз так, то путь это и будет одним и тем же.

лучше представить изначально, что всё - форум.
далее, мы выделяем некоторый раздел и называем его faqом, ставим ему скрытый статус и рисуем отдельную страницу с соответствующим методом заполнения.
тоже самое - гостевая книга, только здесь выделяем отдельную тему в скрытом разделе.
блог - это всего лишь возможность пользователю создавать разделы. по сути это форум групп здесь на винграде.
то есть эти вещи отличаются только заточенным интерфейсом. а скрипты выдачи данных и модули вставки/редактирования/перемещения данных - одни и те же. точнее - всего один класс на задачу