Cotonti / Open Source PHP Content Management FrameworkContent Management Framework

Forumlar / National / Russian / Вопрос по проектированию БД

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

Asmo
#1 2009-01-05 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 2009-01-05 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 2009-01-05 08:17
И база размером с атомный ледокол "Арктика", набитая дубликатами :). Всё же вариант предложенный Асмо более интересен, по крайней мере для меня. Но нужно думать дальше, возможно где-то есть решение простое, красивое и быстрое :)
Born in the Wild Wild East!
esclkm
#4 2009-01-05 14:54
да . но ведь каждый документ у нас не будет дублироваться трижды - хотя...
я себе туго представляю принцип работы таблицы связей - хотя навероне за ней будущее. так как like и 3 отдельных поля - это как по мне весьма непригодные варианты - уж лучше мой
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Trustmaster
#5 2009-01-05 15:26
Если делать мультикатегории для всех (то бишь официально для ядра), то однозначно через промежуточную таблицу связей. Это утяжеляет запросы выборки страниц по категориям (впрочем, даже такие кореллированные запросы работают быстрее, чем обычные с LIKE), но избавляет разработчиков от многих тупиковых ситуаций, которые их поджидают в случае размножения полей в таблице.

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

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