Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
к сожалению, я поторопился закрывать топик :(( 17.06.03 13:18
Автор: tdes <jin> Статус: Member
|
проблема теперь такая :
я думал определить праймари как индекс для родительского поста, но mysql не дает вставить две строки с одинаковым праймари :((
то есть опять не ясно как быть ((((
|
|
можно ли отталкиваться от сортировки таблицы по праймари [mysql} + ряд мыслей 17.06.03 20:14
Автор: tdes <jin> Статус: Member
|
Ситуация следующая:
я изначально наивно пологал, что сабж выполняется, но поговорив с умными людьми, которые мне сообщили, что это не часть sql и поэтому не стоит опираться на физическое представление базы данных ( хотя проведя ряд тестов, я заметил именно сабжевое поведение mysql).
Отсюда и были все вопросы про вставку “в середину”, так как я думал, что просто вызов insert вставляет в конец. Однако если это не так, то возникает вопрос как реализовать древовидную структуру форума. Можно вводить разные поля, такие как id сообщения (mid) , id предка (pid) , время создания (time) и показатель вложенности (dipth), но если не знать как это физически расположено в базе, то единственное, что можно сделать - это select с сортировкой по одному полю, чего не достаточно для древовидного вывода (так как ни сообщения отсортированные по date, ни по mid, pid не определяют правильный порядок)
На данный момент я юзаю такой алгоритм:
сообщения обёдиняются в группы ( subject + ответы), когда добавляется новая группа ( новый топик ) у него id=0 (у топика) , когда постится ответ, то он берёт id родителя прибавляет к нему 1, а для всех постов, у которых id был больше родителя id увеличиваются на один update'ом, таким образом, всегда есть индекс, который говорит в какой последовательности выводить сообщения, кроме того я держу параметр отвечающий за стeпень вложенности сообщения ( на сколько сдвинуть пост)
Что мне не нравится в этом - массавый апдейт при постинге.
Предложения, коментарии ?
|
| |
Post ID менять не надо, а сделать его счетчиком и примари 17.06.03 21:26
Автор: amirul <Serge> Статус: The Elderman
|
> Ситуация следующая:
> я изначально наивно пологал, что сабж выполняется, но
Мое имхо:
Сами данные не сортируются, сортируется индексный файл. Как аналогию можно представить связный список. Последовательность нод этого списка в памяти может быть любой, но при помощи связей список можно отсортировать по любому критерию не меняя положения самих нод.
> поговорив с умными людьми, которые мне сообщили, что это не
> часть sql и поэтому не стоит опираться на физическое
> представление базы данных ( хотя проведя ряд тестов, я
> заметил именно сабжевое поведение mysql).
Таких индексных файлов может быть много, поэтому таблица может быть одновременно отсортирована по многим полям. Соответственно может быть произведен эффективный поиск по любому из них или по их комбинации.
> если это не так, то возникает вопрос как реализовать
> древовидную структуру форума. Можно вводить разные поля,
Вообще то ветвистые деревья (больше двух детей) реализуются хранением в каждой ноде списка указателей на детей. В твоем случае нужно нечто вроде branch id для каждого поста. Можно назвать его и thread, только я привык понимать под этим словом все дерево, начиная от корня, а в данном случае оно хранит только ветку со своими наследниками. БранчИД тоже надо делать в виде счетчика, чтоб каждый новый создаваемый бранч имел новый id. В записи для поста хранить кроме собственного branch id еще и childs branch id.
Работать это должно так. При создании поста (а можно и при первом ответе на него) ему в childs branch id записывается новый (уникальный) id из счетчика. Таким образом создается новая ветка в дереве. Когда на пост с валидным БранчИД дается ответ, этому ответу присваевается БранчИД со значением child branch id своего родителя. Ну и дальше читай с начала этого параграфа :-)
Для удобства навигации по дереву можно добавить parent post id. Не branch id, так как в родительской ветке может быть много братьев (родительского поста) и тогда непонятно к какому именно относится данный пост.
При такой схеме весь форум тоже может быть представлен в виде ветки например с ID = 1, доски - дети форума, ну соответсвенно все треды - дети досок.
Выбрать все дерево одним запросом не получится (насколько я помню SQL не поддерживает рекурсию). Но с другой стороны выборка-то будет делаться из php или perl-а, который вполне способны на оную.
> Предложения, коментарии ?
После добавления поста не надо никаких апдейтов. А сортировать посты с одинаковым branch id можно например по post id или по времени или как угодно еще.
|
| | |
Post ID менять не надо, а сделать его счетчиком и примари 18.06.03 00:17
Автор: tdes <jin> Статус: Member
|
тут ситуация следующая:
php, с которым я работаю ( думаю перл тоже) просто умеет посылать sql queries базе данных, и получать результат в переменной, чтобы построить рекурсию нужно просто несколько запросов послать б. д. В этом плане, алгоритм, которым я сейчас пользуюсь лучше тем, что он делает много запросов только при добавлении поста, а при выводе постов только один селект, и это лучше по той причине, что чтение происходит чаше, чем добавление ( правда не зная внутренней структуры это навряд ли можно утверждать :)) ) , кроме того нет заморочек с запросами - одним апдейтом увеличивается индекс у всех нодов, что надо ( больших нужного), одним селектом все читается.
|
| | | |
Post ID менять не надо, а сделать его счетчиком и примари 18.06.03 02:29
Автор: amirul <Serge> Статус: The Elderman
|
С branch id и child branch id я погарячился - слишком пытался притянуть к аналогичной реализации в C. После трезвого рассуждения действительно достаточно в каждом посте хранить родительский post id.
А насчет слишком много select-ов. Так БД для того и разрабатывается. И должна делать это эффективно.
Ну если уж на то пошло, то чтоб сделать эффективную выборку всех постов какого нибудь треда, то лучше чем куча update-ов, сделать легкую денормализацию таблицы. Например, хранить в каждом посте id корневого поста для данного треда. Тогда выборку всего треда по любому из постов можно произвести одним select-ом, а так как в треде не так много постов, то выстраивать полученный набор в дерево можно или рекурсивными запросами по полученной выборке или обычными методами поиска, но уже на php или perl-е.
|
|
Давно не занимался БД 17.06.03 15:49
Автор: amirul <Serge> Статус: The Elderman
|
> проблема теперь такая :
> я думал определить праймари как индекс для родительского
> поста, но mysql не дает вставить две строки с одинаковым
> праймари :((
> то есть опять не ясно как быть ((((
Но, насколько я помню из теории БД, ключи могут быть не только примари (те по которым производится поиск), и для таких ключей СерверБД тоже создает индекс, так что оставь примари уникальным (обязательное требование нормализации таблицы уж не помню в какой нормальной форме, первой кажется) - ИД поста, а поиск можешь производить по другим ключам (в частности Parent ID) на эффективности поиска это не отразится - поиск по любым ключам (и примари и не примари) должен быть одинаково эффективным, и насколько я себе представляю реализацию - в худшем случае за логарифмическое время. За этим должна следить реализация.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
