cotonti.com : Вопрос по проектированию БД

Trustmaster

Tue, 06 Jan 2009 15:31:28 -0000

Пока это намечено на ветку 0.3.

Dayver

Tue, 06 Jan 2009 06:13:11 -0000

+1 к идее внедрения мультикатегорийности в движок

NovoKain

Tue, 06 Jan 2009 05:14:25 -0000

undefined:
Поддержка наверное должна быть - но выкл\вкл

Абсолютно согласен. Данная функция во всех современных движках присутствует (мультикатегорийность) Тут думаю уместен вопрос о наиболее правильном решении без существенной потери скорости.

Sergeich

Tue, 06 Jan 2009 03:23:47 -0000

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

esclkm

Tue, 06 Jan 2009 03:18:43 -0000

50%50 как по мне смотря что будет из себя представлять сайт и его специализацию. Поддержка наверное должна быть - но выкл\вкл

Asmo

Tue, 06 Jan 2009 02:53:04 -0000

Trustmaster, спасибо, значит я в правильном направлении думал, вчера сделал 3 полями, этот вопрос уже закрыт.
Хотелось бы продолжить тему, в таком ключе - нужна ли мультикатегорийность в cotonti.
То что делать нужно по уму, через таблицу связей - это бесспорно.
Ну например в каталоге это оправдано, а так ли важно иметь это свойство в движке, как в том же вордпресс?

Trustmaster

Mon, 05 Jan 2009 15:26:44 -0000

Если делать мультикатегории для всех (то бишь официально для ядра), то однозначно через промежуточную таблицу связей. Это утяжеляет запросы выборки страниц по категориям (впрочем, даже такие кореллированные запросы работают быстрее, чем обычные с LIKE), но избавляет разработчиков от многих тупиковых ситуаций, которые их поджидают в случае размножения полей в таблице.

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

Страницы-призраки мне не нравятся. Мало того, что данные приходится дублировать, так дубликаты надо еще и синхронизировать между собой.

esclkm

Mon, 05 Jan 2009 14:54:19 -0000

да . но ведь каждый документ у нас не будет дублироваться трижды - хотя...
я себе туго представляю принцип работы таблицы связей - хотя навероне за ней будущее. так как like и 3 отдельных поля - это как по мне весьма непригодные варианты - уж лучше мой

Sergeich

Mon, 05 Jan 2009 08:17:44 -0000

И база размером с атомный ледокол "Арктика", набитая дубликатами :). Всё же вариант предложенный Асмо более интересен, по крайней мере для меня. Но нужно думать дальше, возможно где-то есть решение простое, красивое и быстрое :)

esclkm

Mon, 05 Jan 2009 05:37:52 -0000

читай мнение медика разбирающегося во всем на столько на сколько позволяет интуиция.
еще 1 таблица связей - ой это ужасно. брр
like - даже звучит медленно
гора полей в базе черт а где гибкость
я бы сделал так:
1. 2 пейджа одинаковых создать не сложно - тебе как пхп мостру написать утилиту по дубликации страниц -я думаю расплюнуть
2. но в таблице с пейджами добавил бы еще 1 поле класса link_id (смысл которого - откуда грузить инфу - класса - комменты - и - рейтинг и тд
3. в итоге грузится страница как обычно но вот есть link_id заполнено все наворотики грузит с учетом данной поправки.

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

это мое скромное медицинское мнение)))

Asmo

Mon, 05 Jan 2009 04:37:59 -0000

Делаю тут каталог, возник ряд вопросов по проектированию БД.
Как известно, в СЕ страницу можно привязать только к одной категории, видел я на 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 примеров указывающих на необходимость нормализации, ни один не подходит.

Собственно этот вопрос возникал у меня и раньше, все не устраивало что в СЕ нет мультикатегорийности как в вордпресс, но какой монстр вордпресс и какой шустрый СЕ, на том и стоим ведь :)