Оптимальная структура БД форума
Имеется следующая ERP-модель.
Форум(название) -> Содержит -> Раздел(название) ->
Содержит -> Подраздел(название) -> Содержит -> Тема(последнее сообщение, дата создания, Автор, количество сообщений, количество просмотров) -> Содержит -> Сообщение(содержание, автор, дата).
Дак вот получается, что все сообщения (если эту модель перевести в даталогическую) из всех форумуов будут храниться в одной таблице. => Каждый раз при выводе сообщений необходимо будет осуществлять выборку по такой огромной таблице, просматривая ВСЕ СООБЩЕНИЯ ВСЕХ ФОРУМОВ. Посоветуйте, как лучше сделать, для каждого раздела создавать свою таблицу? Или как?
Вот думаю как лучше.
Имеется следующая ERP-модель.
Форум(название) -> Содержит -> Раздел(название) ->
Содержит -> Подраздел(название) -> Содержит -> Тема(последнее сообщение, дата создания, Автор, количество сообщений, количество просмотров) -> Содержит -> Сообщение(содержание, автор, дата).
Дак вот получается, что все сообщения (если эту модель перевести в даталогическую) из всех форумуов будут храниться в одной таблице. => Каждый раз при выводе сообщений необходимо будет осуществлять выборку по такой огромной таблице, просматривая ВСЕ СООБЩЕНИЯ ВСЕХ ФОРУМОВ. Посоветуйте, как лучше сделать, для каждого раздела создавать свою таблицу? Или как?
А что такого? Действительно разумно все сообщения хранить в одной таблице. =) Только желательно сделать таблицу самих сообщений отдельно...мда криво написал =) имеется ввиду вот что:
Сделать отдельную таблицу сообщений в которой будет хранится только уникальное ИД сообщения и само сообщение(вероятно БЛОБ). Все остальные атрибуты сообщения, как-то ИД юзера кто написал сообщение, ИД темы/форума, дата и т.д. хранить в отдельной таблице. ТОгда при всех манипуляциях с таблицами сервер БД будет опреировать только индексами. Такие опрерации выполняются мили/микро секунды. Когда массив ИД-шек сообщений подготовлен (например выбраны все соответсвуеющие сообщения пользователя, или все новые сообщения или все на к-л дату), то уже достаешь из таблицы непосредственно сами сообщения. Такая схема должна работать довольно быстро, ибо при выполнении запросов сервер не будет заносить в память содержимое полей БЛОБ, а при конечной выборке из той страшной таблицы всех сообщений, которой ты так опасаешься, адресация будет производится по индексу, что тоже очень быстро.
Я не особо силен в веб-программинге, но если бы мне пришлось манипулировать объемными данными сделал бы именно так. Т.е. по возможности манипулировал бы индексами.
А что такого? Действительно разумно все сообщения хранить в одной таблице. =) Только желательно сделать таблицу самих сообщений отдельно...мда криво написал =) имеется ввиду вот что:
Сделать отдельную таблицу сообщений в которой будет хранится только уникальное ИД сообщения и само сообщение(вероятно БЛОБ). Все остальные атрибуты сообщения, как-то ИД юзера кто написал сообщение, ИД темы/форума, дата и т.д. хранить в отдельной таблице. ТОгда при всех манипуляциях с таблицами сервер БД будет опреировать только индексами. Такие опрерации выполняются мили/микро секунды. Когда массив ИД-шек сообщений подготовлен (например выбраны все соответсвуеющие сообщения пользователя, или все новые сообщения или все на к-л дату), то уже достаешь из таблицы непосредственно сами сообщения. Такая схема должна работать довольно быстро, ибо при выполнении запросов сервер не будет заносить в память содержимое полей БЛОБ, а при конечной выборке из той страшной таблицы всех сообщений, которой ты так опасаешься, адресация будет производится по индексу, что тоже очень быстро.
Я не особо силен в веб-программинге, но если бы мне пришлось манипулировать объемными данными сделал бы именно так. Т.е. по возможности манипулировал бы индексами.
Спасибо за совет. А вот какой коэффициент заполнения сделать у страницы индексов в данном случае?
Спасибо за совет. А вот какой коэффициент заполнения сделать у страницы индексов в данном случае?
Что ты имеешь ввиду под коэффициентом заполнения? Что-то видимо я не в теме =)
Сделать отдельную таблицу сообщений в которой будет хранится только уникальное ИД сообщения и само сообщение(вероятно БЛОБ). Все остальные атрибуты сообщения, как-то ИД юзера кто написал сообщение, ИД темы/форума, дата и т.д. хранить в отдельной таблице.
а зачем ид юзера, ид темы, дату хранить отдельно от самого сообщения? т.е. вряд ли для этого сообщения появится еще один ид юзера или еще одна дата.
по Вашему надо слазить как минимум в две таблицы что бы узнать эту информацию, а если хранить в одной, то все будет рядом, ни надо ни куда более смотреть
но это имхо.
а зачем ид юзера, ид темы, дату хранить отдельно от самого сообщения? т.е. вряд ли для этого сообщения появится еще один ид юзера или еще одна дата.
по Вашему надо слазить как минимум в две таблицы что бы узнать эту информацию, а если хранить в одной, то все будет рядом, ни надо ни куда более смотреть
но это имхо.
Совершенно верно, для сообщения не то что не появится юще один юзер и дата, это надо принудительно ограничить констрэйнтами. В частности сделать в поле таблице где хранятся сообщения ИД сообщения - ключем и связать его с ключем таблицы в котором описаны параметры сообщения. Иначе может нарушится целостность данных. Дело не в этом. Дело в том, что этот подход был предложен с целью оптмизации.
Т.е. например когда делаешь выборку из огромной таблицы сообщений, которая к тому же содержит блоб поле в котором хранится само сообщение, то при вычислении каких-либо промежуточных результатов запроса сервер будет заносить в память содержимое всех полей таблицы, включая объемные поля блоб-ов (хотя по сути информация этого поля нам не нужна, по ней мы не будем проверять какие-либо условия в запросе), это может замедлить работу.
Все зависит от сервера БД. Мне кажется, многие относительно современные сервера должны уметь выполнять какую-то оптимизацию сами. Нужно смотреть соответсвующее описание алгоритмов выполнения запросов, читать документацию, а лучше всего никому не доверять =) а смоделировать ситуацию самому, и оценить производительность.
Но т.к. я не знаю с какой БД работал товарисч, то я дал общий совет который, по-моему, имеет право на жизнь. =)