Форумы / National / Russian / Вопрос по проектированию БД

Решении вопроса мультикатегорийно

Asmo
#1 05.01.2009 04:37
Делаю тут каталог, возник ряд вопросов по проектированию БД.
Как известно, в СЕ страницу можно привязать только к одной категории, видел я на seditioforge костыль для решения мультикатегорийности, но коль уж делать решил все с нуля, то и хотелось бы сразу уже правильно.

мне нужно сделать так, чтобы одну страницу можно было добавлять в три разных категории, в идеале в N категорий, где N - кол-во категорий, ограничиваемое в настройках.
Варианты:
1) Отдельно таблица для связей категорий и страниц.
2) Как в костыле с seditioforge - в странице в поле page_cat записывать коды категорий через запятую, а потом при построении списков выбирать через
WHERE page_cat LIKE '%$c%'
3) Сделать три отдельных поля в странице: page_cat1, page_cat2, page_cat3 и выбирать соответсвенно -
WHERE (page_cat1='$c' OR page_cat2='$c' OR page_cat3='$c')
В общем не гибко, сколько полей столько и категорий всего.
Но если разобраться то все равно ограничитель этот будет выставляться один раз, например максимум 3 категории на страницу, а там уже на выбор - хочешь одну, хочешь три. Так что собственно это требование не критичное.

Вот хочу испросить совета как лучше это сделать.
Страниц будет очень много, ибо это каталог будет.
Я остановился на третьем варианте, идея с LIKE и второй таблицей мне не очень нравится из-за моей паранойи по поводу производительности.

Интересует, какой из вариантов, на ваш взгляд, предпочтительнее с оглядкой на производительность, нагрузку на БД.

Что скажут профессиональные прогеры я в общем то догадываюсь :) это 1 вариант, мне уже открыли глаза на "Нормализацию баз данных", хоть я и добросовестно прочел об этом все по ссылке на вики, но не уловил связи с моим случаем, из 5 примеров указывающих на необходимость нормализации, ни один не подходит.

Собственно этот вопрос возникал у меня и раньше, все не устраивало что в СЕ нет мультикатегорийности как в вордпресс, но какой монстр вордпресс и какой шустрый СЕ, на том и стоим ведь :)
esclkm
#2 05.01.2009 05:37
читай мнение медика разбирающегося во всем на столько на сколько позволяет интуиция.
еще 1 таблица связей - ой это ужасно. брр
like - даже звучит медленно
гора полей в базе черт а где гибкость
я бы сделал так:
1. 2 пейджа одинаковых создать не сложно - тебе как пхп мостру написать утилиту по дубликации страниц -я думаю расплюнуть
2. но в таблице с пейджами добавил бы еще 1 поле класса link_id (смысл которого - откуда грузить инфу - класса - комменты - и - рейтинг и тд
3. в итоге грузится страница как обычно но вот есть link_id заполнено все наворотики грузит с учетом данной поправки.

ИТОГ:
1. потери на скорости 0 - ведь дополнительных запросов нет и like и dislike )))) тоже нет, дополнительные базы не создавались
2. каждая стрница создана отдельно - на самом деле небольшой минус то ведь) - при желании можно накрутить что они будут синхронно редктироваться - несложно ж вроде
3. аналогичные страницы могут использовать одинаковые комменты - это плюс
4. если человек добавил страницу в несколько категорий и стоит плагин автоматического добавления страниц - страница утвердиться только там где у человека админ привелегии.-супер плюс
5. проработать механиз подтверждения одинаковых страниц - это минус

это мое скромное медицинское мнение)))
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Sergeich
#3 05.01.2009 08:17
И база размером с атомный ледокол "Арктика", набитая дубликатами :). Всё же вариант предложенный Асмо более интересен, по крайней мере для меня. Но нужно думать дальше, возможно где-то есть решение простое, красивое и быстрое :)
esclkm
#4 05.01.2009 14:54
да . но ведь каждый документ у нас не будет дублироваться трижды - хотя...
я себе туго представляю принцип работы таблицы связей - хотя навероне за ней будущее. так как like и 3 отдельных поля - это как по мне весьма непригодные варианты - уж лучше мой
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Trustmaster
#5 05.01.2009 15:26
Если делать мультикатегории для всех (то бишь официально для ядра), то однозначно через промежуточную таблицу связей. Это утяжеляет запросы выборки страниц по категориям (впрочем, даже такие кореллированные запросы работают быстрее, чем обычные с LIKE), но избавляет разработчиков от многих тупиковых ситуаций, которые их поджидают в случае размножения полей в таблице.

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

Страницы-призраки мне не нравятся. Мало того, что данные приходится дублировать, так дубликаты надо еще и синхронизировать между собой.
May the Source be with you!
Asmo
#6 06.01.2009 02:53
Trustmaster, спасибо, значит я в правильном направлении думал, вчера сделал 3 полями, этот вопрос уже закрыт.
Хотелось бы продолжить тему, в таком ключе - нужна ли мультикатегорийность в cotonti.
То что делать нужно по уму, через таблицу связей - это бесспорно.
Ну например в каталоге это оправдано, а так ли важно иметь это свойство в движке, как в том же вордпресс?
esclkm
#7 06.01.2009 03:18
50%50 как по мне смотря что будет из себя представлять сайт и его специализацию. Поддержка наверное должна быть - но выкл\вкл
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Sergeich
#8 06.01.2009 03:23
Вещь полезная, помнится мучался я на одном проекте и основные мучения были именно с дублированием контента. С другой стороны сейчас вводят теги в движок, они выполняют схожие функции (но не совсем :) )
NovoKain
#9 06.01.2009 05:14
undefined:
Поддержка наверное должна быть - но выкл\вкл
Абсолютно согласен. Данная функция во всех современных движках присутствует (мультикатегорийность) Тут думаю уместен вопрос о наиболее правильном решении без существенной потери скорости.
Dayver
#10 06.01.2009 06:13
+1 к идее внедрения мультикатегорийности в движок
Pavlo Tkachenko aka Dayver
Trustmaster
#11 06.01.2009 15:31
Пока это намечено на ветку 0.3.
May the Source be with you!