Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Оптимальная структура БД форума

422
09 апреля 2006 года
Dimarik
181 / / 12.02.2005
Вот думаю как лучше.

Имеется следующая ERP-модель.

Форум(название) -> Содержит -> Раздел(название) ->
Содержит -> Подраздел(название) -> Содержит -> Тема(последнее сообщение, дата создания, Автор, количество сообщений, количество просмотров) -> Содержит -> Сообщение(содержание, автор, дата).

Дак вот получается, что все сообщения (если эту модель перевести в даталогическую) из всех форумуов будут храниться в одной таблице. => Каждый раз при выводе сообщений необходимо будет осуществлять выборку по такой огромной таблице, просматривая ВСЕ СООБЩЕНИЯ ВСЕХ ФОРУМОВ. Посоветуйте, как лучше сделать, для каждого раздела создавать свою таблицу? Или как?
385
10 апреля 2006 года
SomewherSomehow
477 / / 25.07.2004
Цитата:
Originally posted by Dimarik
Вот думаю как лучше.

Имеется следующая ERP-модель.

Форум(название) -> Содержит -> Раздел(название) ->
Содержит -> Подраздел(название) -> Содержит -> Тема(последнее сообщение, дата создания, Автор, количество сообщений, количество просмотров) -> Содержит -> Сообщение(содержание, автор, дата).

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



А что такого? Действительно разумно все сообщения хранить в одной таблице. =) Только желательно сделать таблицу самих сообщений отдельно...мда криво написал =) имеется ввиду вот что:
Сделать отдельную таблицу сообщений в которой будет хранится только уникальное ИД сообщения и само сообщение(вероятно БЛОБ). Все остальные атрибуты сообщения, как-то ИД юзера кто написал сообщение, ИД темы/форума, дата и т.д. хранить в отдельной таблице. ТОгда при всех манипуляциях с таблицами сервер БД будет опреировать только индексами. Такие опрерации выполняются мили/микро секунды. Когда массив ИД-шек сообщений подготовлен (например выбраны все соответсвуеющие сообщения пользователя, или все новые сообщения или все на к-л дату), то уже достаешь из таблицы непосредственно сами сообщения. Такая схема должна работать довольно быстро, ибо при выполнении запросов сервер не будет заносить в память содержимое полей БЛОБ, а при конечной выборке из той страшной таблицы всех сообщений, которой ты так опасаешься, адресация будет производится по индексу, что тоже очень быстро.
Я не особо силен в веб-программинге, но если бы мне пришлось манипулировать объемными данными сделал бы именно так. Т.е. по возможности манипулировал бы индексами.

422
11 апреля 2006 года
Dimarik
181 / / 12.02.2005
Цитата:
Originally posted by SomewherSomehow
А что такого? Действительно разумно все сообщения хранить в одной таблице. =) Только желательно сделать таблицу самих сообщений отдельно...мда криво написал =) имеется ввиду вот что:
Сделать отдельную таблицу сообщений в которой будет хранится только уникальное ИД сообщения и само сообщение(вероятно БЛОБ). Все остальные атрибуты сообщения, как-то ИД юзера кто написал сообщение, ИД темы/форума, дата и т.д. хранить в отдельной таблице. ТОгда при всех манипуляциях с таблицами сервер БД будет опреировать только индексами. Такие опрерации выполняются мили/микро секунды. Когда массив ИД-шек сообщений подготовлен (например выбраны все соответсвуеющие сообщения пользователя, или все новые сообщения или все на к-л дату), то уже достаешь из таблицы непосредственно сами сообщения. Такая схема должна работать довольно быстро, ибо при выполнении запросов сервер не будет заносить в память содержимое полей БЛОБ, а при конечной выборке из той страшной таблицы всех сообщений, которой ты так опасаешься, адресация будет производится по индексу, что тоже очень быстро.
Я не особо силен в веб-программинге, но если бы мне пришлось манипулировать объемными данными сделал бы именно так. Т.е. по возможности манипулировал бы индексами.



Спасибо за совет. А вот какой коэффициент заполнения сделать у страницы индексов в данном случае?

385
12 апреля 2006 года
SomewherSomehow
477 / / 25.07.2004
Цитата:
Originally posted by Dimarik
Спасибо за совет. А вот какой коэффициент заполнения сделать у страницы индексов в данном случае?


Что ты имеешь ввиду под коэффициентом заполнения? Что-то видимо я не в теме =)

15K
21 апреля 2006 года
y4an
27 / / 20.04.2006
Цитата:
Originally posted by SomewherSomehow
Сделать отдельную таблицу сообщений в которой будет хранится только уникальное ИД сообщения и само сообщение(вероятно БЛОБ). Все остальные атрибуты сообщения, как-то ИД юзера кто написал сообщение, ИД темы/форума, дата и т.д. хранить в отдельной таблице.


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

385
21 апреля 2006 года
SomewherSomehow
477 / / 25.07.2004
Цитата:
Originally posted by y4an
а зачем ид юзера, ид темы, дату хранить отдельно от самого сообщения? т.е. вряд ли для этого сообщения появится еще один ид юзера или еще одна дата.
по Вашему надо слазить как минимум в две таблицы что бы узнать эту информацию, а если хранить в одной, то все будет рядом, ни надо ни куда более смотреть
но это имхо.



Совершенно верно, для сообщения не то что не появится юще один юзер и дата, это надо принудительно ограничить констрэйнтами. В частности сделать в поле таблице где хранятся сообщения ИД сообщения - ключем и связать его с ключем таблицы в котором описаны параметры сообщения. Иначе может нарушится целостность данных. Дело не в этом. Дело в том, что этот подход был предложен с целью оптмизации.
Т.е. например когда делаешь выборку из огромной таблицы сообщений, которая к тому же содержит блоб поле в котором хранится само сообщение, то при вычислении каких-либо промежуточных результатов запроса сервер будет заносить в память содержимое всех полей таблицы, включая объемные поля блоб-ов (хотя по сути информация этого поля нам не нужна, по ней мы не будем проверять какие-либо условия в запросе), это может замедлить работу.
Все зависит от сервера БД. Мне кажется, многие относительно современные сервера должны уметь выполнять какую-то оптимизацию сами. Нужно смотреть соответсвующее описание алгоритмов выполнения запросов, читать документацию, а лучше всего никому не доверять =) а смоделировать ситуацию самому, и оценить производительность.
Но т.к. я не знаю с какой БД работал товарисч, то я дал общий совет который, по-моему, имеет право на жизнь. =)

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог