- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Ну елки-палки... Тема интересная, но опять сваливается на флуд. Давайте уж как-то формализуем условия задачи.
Типа так:
1) nested sets использовать нельзя;
2) рекурсия — плохо;
3) хранимых процедур, триггеров и т. п. нет. Чистый sql.
4) кешировать можно (?)
Вот, для затравки, бредовое дерево у себя нашел:
Polimer, если под рекурсией понимается построение дерева на основе парентов, то жизнь существенно облегчит хранение в таблице левела.
Что касается всего остального, то при текущей постановке задачи (1000 записей, 5 уровней) неплохим вариантом является хранение в таблице пути к узлу
AndreM, а, вот тут-то мы и добрались до самого интересного, бишь до кеширования. Тогда внимание вопрос: если мы кэшируем дерево целиком, нам не пофигу, как его выбирать? Хоть тыщей запросов :) И еще вопрос: а зачем кэшировать промежуточно-абстрактное "дерево целиком", если можно закешировать результаты?
Насчет зависающих процессов - это надо смотреть на Вашу конкретную систему. Убейте, не пойму, где должен повиснуть запрос, достающий 1 запись по primary :)
ОК, а как Вы решаете задачу поиска в категории?
timur-kar, да, именно так. Ну, с небольшими хитростями.
1. Категории обновляются, то есть кэшируем мы на несколько минут. Кэшируется и весь результат, но дерево категорий используется и в некэширующихся местах. То есть имеем частичное кэширование.
2. 1 запрос по праймари не виснет, виснет очередь из нескольких тысяч таких запросов в секунду. К тому же паралельно много и других, довольно тяжелых запросов. Одно дерево нафиг никому не нужно по большому счету, нужно в сочетании.
3. Эффективный поиск пока в разработке, сейчас обычный полнотекстовый поиск по базе с указанием id категорий.
4. Рекурсия - не плохо, это математика и это хорошо. Только с умом.
5. Хранить левел - это удобно выводить, но не удобно обновлять, если что, кучи апдейтов и насилование мозга, не дай бог цифирку упустить. Было, проходили уже.
6. Путь к узлу не решит все задачи.
В общем все эти задачи у меня решаются один запросом, который я написал выше. На практике работает в целом отлично.
Ну елки-палки... Тема интересная, но опять сваливается на флуд. Давайте уж как-то формализуем условия задачи.
1) nested sets использовать нельзя;
Вообще да, тема очень интересная, но сваливается к тому что раз уж кешируем то как хранить и выбирать не очень важно :)
А вот почему nested sets использовать нельзя ? в том смысле что если "поверх" как предлагает Коля Дубр (т.е. не нарушая исходные условия задачи с хранением parent_id) то выборки там очень удобные и быстрые получаются, а рассчитывать (синхронизовывать иерархии) его нужно только при изменении структуры дерева (что обычно происходит нечасто)
а рассчитывать (синхронизовывать иерархии) его нужно только при изменении структуры дерева (что обычно происходит нечасто)
Ну, например, если комментарии хранятся в виде вложенных множеств, а они могут быть ещё и вложенными, то изменения могут происходить часто (реже чем выборки, но всё же).
Насчёт хранимых процедур и триггеров, то делать их на таблицах без поддержки транзакций может вылезти боком :)
кэширование не заменяет оптимальный алгоритм построения деревьев, это просто некая следующая ступень оптимизации.
то выборки там очень удобные и быстрые получаются
Зато там очень неудобный INSERT и перенос веток. Поэтому я использую не одно большое дерево, а "лес" - в этом хитрость.
5. Хранить левел - это удобно выводить, но не удобно обновлять, если что, кучи апдейтов и насилование мозга, не дай бог цифирку упустить. Было, проходили уже.
Если операции изменения БД централизовать в каком-то одном специальном классе - этот код достаточно написать один раз, оттестировать как следует, и больше не задумываться о нем.
Ладно, я пойду бухать корпоратив и придумывать каверзные контраргументы, завтра Вас еще потерзаю :) Спасибо за интересную дискуссию.
обновлять левелы трудоемко для базы, да и по сути излишняя это инфа, хотя можеть быть это то, где избыточность полезна... в общем на примерах смотреть нужно, что то мне не нравится эта идея...
Ладно, я пойду бухать корпоратив и придумывать каверзные контраргументы, завтра Вас еще потерзаю :) Спасибо за интересную дискуссию.
не за что )) давай те лучше в понедельник, завтра выходные, отдыхать от компа надо... надо придумать еще что нибудь интересное.
кстати, чего исключили возможность использовать nested sets?
ИМХО, с его помощью или с помощью подобных алгоритмов, можно решить почти любую задачу по хранению дерева в БД майскьюэль лучше, чем с помощью других...
MOP1 добавил 04.10.2008 в 21:27
где-то проскальзывала ссылка
вот что там я увидел:
эм... вообщето дерево такой структуры строится без рекурсии ;)
Зачем тратить процессорное время сервера на постройку дерева? Пускай у клиента браузер его и строит :)
Помнится давно как-то писал такую фиговину... Если найду, то выложу.
Не совсем то оказывается писал, но тоже дерево :)