- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Господа, кто нить пробовал http://php.russofile.ru/ru/authors/sql/nestedsets01 ?
Попробовал использовать в своей cms, вместо структуры базы id, pid,... , вывод-то наладил.
Но, допустим заходим в редактирование категории (не драгабл и отлов айди дропабла джикверей и обработка) по-старинке выбором селекта и передачей в пост запросе:
ну и потом в методе так:
.Собственно если родитель категории меняется то мы ее $this->_dbtree->MoveAll, потом остальные изменения полей (тайтл, контент, дескрипшн, атрибуты разные).
В общем вопрос такой: после $this->_dbtree->MoveAll как то нереально все переколбашивает, то есть бывает что рут вдруг станет чьим то сыном, однако над ним операций не проводилось (он скрыт от пользователя вообще). Как быть?
использую в многих проектах, правда переделанную и с другим драйвером базы данных. все работает отлично
vavenko добавил 14.09.2011 в 11:09
покажите свой MoveAll
То есть то что я показал должно работать? :)
Может там надо как то переструктурировать после МувОл() еще одним запросом?
Вообще мне как то эта избыточность не нравиться очень, id-parent_id ну будет лучше, если дерево генериться только в админке (допустим под каждый модуль своя база т. е. категории, магазин, а дети категорий, соответственно в отдельных базах лежат и так же parent_id у них равен id у базы категорий) и при выводе карты сайта.
Если глубина не больше 4, ну край, 5 уровней, а категорий в базе не больше 1000 (вообще не больше 100 по идее) есть ли смысл в nested sets?
ze6ra добавил 14.09.2011 в 11:14
Весь метод редактирования статьи (со всей его кривизной):
какой способ хранения деревьев использовать - не зависит от глубины вложенности.
разные способы хороши для разных задач:
+: выборка всех непосредственных детей для заданной вершины – очень быстро
-: выборка всех детей для заданной вершины (всего поддерева) – долго
-: выборка всех родителей для заданной вершины (определение пути) – долго
-: определить размер поддерева – долго
-: порядок элементов в уровне не может храниться в структуре дерева
-: проверка, является ли одна вершина дочерней по отношению к другой – долго, если вершины не являются непосредственными родственниками
+: добавление новых элементов в дерево – быстро
-: удаление ветки дерева – долго
+: перемещение веток дерева – быстро
+: количество узлов в дереве – не ограничено
?: устойчивость к ошибкам – средняя (если «исчезает» какой-то элемент, то исчезает только соответствущее поддерево)
+: понимание – легко
2. Вложенные множества (Nested Sets)
?: выборка всех непосредственных детей для заданной вершины – выполняется одним запросом, но долго (без использования индексов) в случае, если этой вершине соответствует поддерево значительных размеров.
+: выборка всех детей для заданной вершины (всего поддерева) – быстро
?: выборка всех родителей для заданной вершины (определение пути) – выполняется одним запросом, но часто без использования индексов (долго).
+: определить размер поддерева – очень быстро
+: структура дерева позволяет задавать порядок элементов в уровне
+: проверка, является ли одна вершина дочерней по отношению к другой – очень быстро
-: добавление новых элементов в дерево – долго
+: удаление ветки дерева – быстро
-: перемещение веток дерева – долго
+: количество узлов в дереве – не ограничено
-: устойчивость к ошибкам – низкая (если «исчезает» какой-то элемент, то все дерево становится неправильным)
?: понимание – разобраться в операциях выборки – просто, в операциях модификации – сложно
поэтому хранить структуру сайта, которую иногда редактирует админ в нестед сетс хорошо, а структуру форума где ветки создают пользователи - плохо.
пс. покажите метод MoveAll вместо редактирования статьи
проверьте параметры, которые передаете в метод MoveAll и так же проверьте целостность вашего дерева:
http://webscript.ru/stories/04/09/01/8197045 (раздел УПРАВЛЕНИЕ ДЕРЕВОМ КАТАЛОГОВ)
Спасибо, покопаю в этом направлении. Потом по результату отпишусь в каком месте был балбесом :)
давно пришёл к личному заключению, что для NS/AL/MP в качестве библиотечного кода больше всего подходят хранимки с динамическим SQL-ем, сейчас только так и делаю. (производительность, не смотря на динамику, всё-равно больше, как мне показалось, и без этих лишних библиотек, а отдельное полноценное решение в своём слое доступа данных)
Вроде работать все правильно начало, балбесом был в этом месте именно, которое и показал вначале:
Так как NS чувствительны к данным положения нода, а редактирование узла у меня после смены его места, понятно что именно данные положения нода (лефт, райт, левел) брались из старого положения нода (остатки грубого перемещения от старой системы id-pid остались, а переменная с новым pid проверялась ниже этого кода и была забыта).
- вот так работает, еще почистить ифы осталось, но работает :)