nested sets, скорость и привязка к структуре сайта

[idencial]

nested sets, скорость и привязка к структуре сайта

Автор класса по работе с nested sets рекомендовал следующее

опыт показывает, что структуру с обходом дерева лучше хранить отдельно от
данных, т.к. в этом случае при обновлении таблицы очень долго обновляются
индексы, да и данные могут сделать невозможным формат записи фиксированной
длины, что тоже кардинально скажется на скорости.
Самой оптимальной структурой по-моему будет:
CREATE TABLE categories (
cat_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
cat_left INT UNSIGNED NOT NULL,
cat_right INT UNSIGNED NOT NULL,
cat_level INT UNSIGNED NOT NULL,
PRIMARY KEY(cat_id)
KEY (cat_left, cat_right, cat_level)
);
В итоге MySQL за многими запросами даже не будет обращаться к файлу с данными.
Ему будет хватать файла с индексами. А когда уже пройдёт всё фильтрование в
таблице с деревом, по примари-кею быстро произойдёт линкование с остальными
данными.

Предположим, что в дополнение к этой структуре я делаю таблицу

table page
-----------------
p_id
p_title
p_content
p_is_active

Казалось бы так можно связать мои странички со структурой, но хочется следующего

1. Хочется хранить ифнормацию о том, что элемент структуры является, например, не конкретной страницей, а разделом.
Т.е для этого элемента не формировать страницу изходя из введенного контента, а просто выводить каталог страниц этого раздела

2. Хочется хранить информацию о том, что элемент структуры является, например, не конкретной страницей, а каким-то модулем,
например, фотоальбомом или модулем новостей


В связи с этим возникает несколько вопросов

1. Где лучше хранить параметр p_is_active. Ведь это относится к элементу структуры и я не хочу выводить в меню сайта элементы, у которых p_is_active = false
Можно хранить в таблице page, но тогда мы при выводе меню делаем запрос с объединением и значит теряем в скорости

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

ЗЫ.
Просто очень хочется не трогать таблицу categories

 

[гоша]

Таблица с данными тебе понадобится с любом случае (ты же не только cat_left итп выводить собираешься). Так что всё равно.

> запрос с объединением и значит теряем в скорости

если индексы правильные -- ничего не теряем.

 

[idencial]

Таблица с данными тебе понадобится с любом случае (ты же не только cat_left итп выводить собираешься). Так что всё равно.

Я понимаю, что таблица с данными нужна, поэтому и привел таблицу page

Вопрос в том где лучше хранить различные признаки: в page or categories
При формировании меню не хочется трогать page

+ вопрос был про разделы и модули (как лучше реализовать)

 

[гоша]

> При формировании меню не хочется трогать page

и что же будет написано в этом меню? Цифры (cat_left, cat_right) или всё-таки слова (названия разделов, страниц итп)? Объединять "categories" и "pages" в запросе тебе придется в любом случае. Поэтому совершенно без разницы, где хранить те или иные "признаки". Если

> хочется не трогать таблицу categories

то и не трогай...

 

[idencial]

Ок, предположим буду делать объединение.
Надеюсь на скорости это не сильно отразится, но хотелось бы еще разрешить пару вопросов, а именно

как лучше сделать связь с модулями (типа новостей) и как лучше поступить с признаком раздел

 

[idencial]

По поводу разделов:
В принципе, если элемент - лист - это страница, если нет - раздел, но при такой реализации есть минусы
1. Нужны доп. проверка лист или нет, а значит при большой посещаемости потеря в скорости
2. Все разделы будут оформлены одинаково - нет гибкости

По поводу модулей:
Немного уточню
Предположим есть модуль новостей и таблица news, модуль статей и таблица articles, модуль фотоальбома и таблицы gallery & photos и т.д.

Предположим я ввожу в таблицу page поле module_id, причем если оно ноль, то это обычная страница или раздел, а иначе я по этому полю имею свясь с таблицей modules, откуда беру информацию о названии модуля и ссылку на дирикторию с ним.

Остается одна проблема.
Как связать таблицы, типа news, articles и т.д. со структурой сайта, т.е чтобы в схеме базы не висело отдельных таблиц?

 

[Aivar]

В отдельной таблице пропиши поле type в котором храниться тип контента, контент соответственно text
type например, 0 - простая страница, 1- ссылка, 2 - раздел, 3 - раздел со страницей, 4 - форум (а ID, если нужно сделать, скажем несколько форумов или гостевых - итак передается на файл ядра. А из него с параметром id вызывай нужный модуль)

И стоит ли инфу о модулях хранить в базе? Может лучше просто сканить каталог modules, выводить список на выбор модуля, потом вставлять в контент тип - модуль, имя модуля - контент таблицы.
Или я вопроса не понял

 

[idencial]

нет, я говорил немного не о том.
Есть например таблица
news
__________
news_id
news_title
news_text

и др. таблицы, относящиеся к определенным модулям, которые я буду постянно добавлять.

Мне самое важное чтобы таблицы не висели в пустоте, т.е все должно быть связано

Пока я не совсем понял как сделать это (связать таблицы, относящиеся к модулям) введя отдельную таблицу с контентом

Кроме это не хочется все делать через индексный файл и для новостей, например, использовать www.site_name.ru/news/

Также, при твоем подходе (с таблицей контента) сложно будет генерить главное меню.

Я там хочу для новостей, например, ставить ссылку на www.site_name.ru/news/

При этом объединения более 2 таблиц будет не совсем быстро

 

[Aivar]

/news/ если я не ошибаюсь, можно сделать через mod_rewrite к апачу. Как точно - не знаю Но можно
У меня меню админятся так: админ в форме прописывает имя меню, указывает файл шаблона, дипазон id для меню (напр. 1,2,3,15-25,200-9999) и уровень вложенности (2 обычно). После этого в шаблон в нужном месте вставляется {$MenuName} все

Таблицы с новостями по полям сильно будут отличаться от обычной таблицы с контентом? Может лучше все-таки сделать универсальную таблицу? Одно дерево на всех, одна таблица контента.

Расскажите мне, чайнику, как будет быстрее - в двух таблицах или в нескольких поменьше? Для меня вопрос актуальный

 

[idencial]

Про mod_rewrite
Я не за красотой гонюсь, а чтобы обрабатывал все не один файл.
Когда все обрабатывает один файл - это считай проблемы с нагрузкой.

Кроме того универсальной таблицы с контентом лучше тоже избегать, т.к

Я, например, новости привел к примеру, а могла быть фотогалерея, голосования или еще что-то

Нужна система, при которой ты можешь добавлять новые модули, но при этом те таблицы из новых модулей автоматом связывать с текущей системой