Какова оптимальная структура БД для многопоточного форума?

Я хочу создать многопоточный форум для электронного сайта (opensource asp.net mvc ofcourse, хотя для этого вопроса это не имеет значения).

Какой должна быть структура БД, которая поможет получать сообщения форума с оптимальной производительностью? Я не ставлю нет. к нему, поскольку он может варьироваться в зависимости от количества извлекаемых строк.

Кроме того, я должен быть в состоянии связать определенную тему с другими темами. Например, показать "Ссылки по теме на форуме".

Я использую SQL Server 2005.

Ниже приведена структура, которую я имею в виду (бесстыдно воспринял) Стивен Вальтер: Отличное сообщение в блоге

Таблица: Форум

· Id
· ParentId  (null if this is the first message)
· ParentThreadId  (Identify message in the same thread)
· Author
· Subject
· Body
· PostedDate

Таблица: RelatedForum

· ForumId
· RelatedForumId

Идеи / предложения приветствуются.

Заранее спасибо.

12.12.2008 08:30:28
Спасибо за все ответы. Я по-прежнему буду держать этот вопрос открытым, чтобы получить больше информации и, поскольку у меня еще есть время, чтобы доработать общий дизайн.
rajesh pillai 12.12.2008 15:28:46
3 ОТВЕТА
РЕШЕНИЕ

Если у вас имеется нерекурсивный нисходящий (ваш форум -> поток -> публикаций) поиск ваших данных для наиболее распространенного случая использования, тогда эта структура таблицы будет хорошим началом, поскольку это приведет в основном к WHERE ParentId = @SomeIdзапросам.

Когда вы захотите вычислить такие вещи, как «Сколько сообщений существует в этом форуме / ветке?», Вы легко попадете в ситуацию, когда вы не сможете определить, какие идентификаторы вложены в какие другие идентификаторы (то есть отношения детей являются отсутствует).

Вы могли бы объяснить это путем избыточного сохранения ThreadIdи ForumIdв каждой публикации. Тогда вы сможете спросить SELECT COUNT(*) FROM Postings WHERE ThreadId = @SomeId.

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

Чтобы получить более продвинутые способы хранения иерархических данных в СУБД, вы можете найти ответы на этот вопрос (это мой собственный вариант, не предусматривающий «поднятия голосов»): «Какой самый эффективный / элегантный способ разбора плоской таблицы» в дерево? "

2
23.05.2017 12:01:17
Это действительно выглядит интересно. Я посмотрю на это.
rajesh pillai 12.12.2008 08:53:48

Таблица: сообщение

· ThreadId
· UUID
· Author
· Subject
· Body
· PostedDate  

Таблица: нить

·ThreadID
·Forum
·UUID
·Author
·Subject
·Body
·PostedDate

Только на сервере MySQL с кэшированием и индексированием. В противном случае эта структура не самая лучшая, но с указанным сервером это облегчает подсчет и полнотекстовый поиск

0
12.12.2008 08:54:34
Было бы гораздо полезнее, если бы вы объяснили почему!
eliego 12.12.2008 09:35:07

Выглядит хорошо. Я бы назвал ParentThreadID просто ThreadID. Добавление ForumID не повредит, особенно для подсчета.

Вы должны добавить AuthorName. Предположительно Author - это идентификатор вашей пользовательской таблицы. Вытащите это имя пользователя и прикрепите его сейчас. Это избавляет вас от необходимости поиска 50 имен из пользовательской таблицы при отображении списка тем или ответов. Точно так же, если пользователь удаляется из системы, вы больше не можете искать его имя. И, конечно, не хочу удалять эти узлы из дерева.

0
12.12.2008 09:19:57
Да. Автор - это идентификатор из пользовательской таблицы. Да, я согласен с названием ThreadId.
rajesh pillai 12.12.2008 15:24:30