У кого какие потребности к форумам, гостевым и прочим комментариям были? Ну там модерирование сообщений, еще что ?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Форум и комментарии в одной таблице |
| Автор: ksnk 6.12.2010, 11:41 | ||
| Хочется получить схему хранения данных для списка задач -- минифорум -- блог -- комментарии к статьям на сайте -- сервис "FAQ", "Вопрос-ответ" -- гостевая книга. Зачем? Для сайта часто хочется вставить одно, другое или третье, а плодить лишние таблицы и код, их поддерживающий не хочется. предварительный список задач, которые должна поддерживать схема хранения данных -- работать с авторизацией и без. От минифорума потребуется -- создавать разделы, достаточно ветвистые по темам -- выводить постранично все ответы в разделе -- поиск по тексту сообщения, по индексу "цитируемого поста", по пользователю -- "новые сообщения с последнего посещения" От блога -- Создавать разделы -- размещать комментарий в разделе -- комментировать другие комментарии -- поиск по тексту комментария, пользователю гостевая - частный случай форума FAQ - частный случай гостевой придумалась такая схема таблицы (mysql)
Вероятно, здесь не хватает fulltext индекса для поля text, но я пока в раздумьях о выборе поискового движка. при ближайшем рассмотрении - это обычное Adjacency List дерево примерная дисциплина универсальной работы Если пользователь авторизован - заполняется поле user, если юзер не авторизован или желает выглядеть по новому - заполняем поле username Все поля, по которым возникает потребность искать - вынесены в отдельные поля. Все поля сообщения, которые достаточно только выводить - сериализуются в поле info. потеря скорости на этой операции не будет сильно сказываться, так как поля используются только для вывода информации и вывод на страницу идет постранично. примерный алгоритм работы с "комментариями" -- в комментарии присутствует> кроме юзера, текста и даты еще "цитируемый участок текста" и "цитируемый комментарий", соответственно, поля "quote" (сериализуется в info) и quote_id. Для каждого "места подключения комментария" на странице заводится пустая строка в таблице forum_tree. Ее индекс и будет parent'ом для всех комментариев этой точки. Для форума, гостевой книги, и т.д., также заводится "root"-овая строчка, от которой уже будем получать весь список тем форума. Индекс рутовой строки должен быть сохранен в конфигурации сайта. Таким образом в одной таблице имеется возможность хранить довольно много форумов, блогов и прочих фенечек. |
| Автор: ksnk 6.12.2010, 16:50 |
| А! вопрос то я не задал У кого какие потребности к форумам, гостевым и прочим комментариям были? Ну там модерирование сообщений, еще что ? |
| Автор: Muerto 6.12.2010, 20:07 |
| Имхо извращение Вещь вроде faq вопрос ответ как правильо маленькая и легенькая таблица... То что ты пытаешься сотворить , это большой не поворотливый монстр  Какие преимущества держать все в одной таблице? Есть какая то средняя грань... явное дело что для каждого сообщения отдельная таблица не нужна... но и все в одну пихать не правильно! |
| Автор: ksnk 6.12.2010, 20:57 | ||||||
Мне как-то попался faq с возможностью комментирования.
Код, который управляет таблицей (вставка-удаление-список-поиск) сидит в одном месте и несложно портируется на нужные нужды. "модельный" интерфейс всех этих вещей imho, примерно одинаковый, хотя faq, возможно, немного более одинаковый чем другие. ;) в faq, если его делать одной таблицей, достаточно пары полей - вопрос ответ. возможно еще дата, как привязка ко времени и способ изменить порядок вывода. если вспомнить о пользователе, который задал вопрос и о пользователе, который ответил. то почти все поля моей таблицы удастся заполнить... Деревянность, разве что не очень нужна для faq/ но если бить его на разделы, то почему бы и нет...
Мне пока так не кажется. Во всяком случае, поиск и вывод информации достаточно шустрый. Какая-то потеря производительности имеет место быть при десериализации "комплексного" поля(info), но если не пихать туда очень большие данные и не требовать поиска по ним - то задержка незначительна. Для поиска по тегам (как в этом форуме) придется, видимо, мастерить отдельную таблицу все равно. Хотя нужен ли поиск по введенным кем-то там тегам? Мне тут до сих пор не пригодился, а для "минифорума", как я его вижу, такое можно и не делать. Вероятно, отдельная таблица нужна и для индексированного поиска. В поле text будет сидеть, как правило, html, а по нему как-то не очень интересно искать fulltext'ом. слишком много угловых скобок, так что в отдельной таблице - лишенный форматирования текст с адресом страницы... ну а самое главное - форум и гостевая - "небольшие", то есть заботится об оптимальном расходовании памяти пока не приходится, и пара лишних полей в базе - не критична. к тому-же, на мой взгляд, самые наполняемые разделы - комментарии и форум, а там все поля используются... |
| Автор: bars80080 6.12.2010, 23:34 |
| имхо таково, что по сути - это одинаковые вещи. а раз так, то путь это и будет одним и тем же. лучше представить изначально, что всё - форум. далее, мы выделяем некоторый раздел и называем его faqом, ставим ему скрытый статус и рисуем отдельную страницу с соответствующим методом заполнения. тоже самое - гостевая книга, только здесь выделяем отдельную тему в скрытом разделе. блог - это всего лишь возможность пользователю создавать разделы. по сути это форум групп здесь на винграде. то есть эти вещи отличаются только заточенным интерфейсом. а скрипты выдачи данных и модули вставки/редактирования/перемещения данных - одни и те же. точнее - всего один класс на задачу |
