Друзья, а скажите пожалуйста, у кого когда последний раз получалось придумать конфигурацию для эксперимента, чтоб ссылочное не работало? :)
На своем личном ресурсе Вы вполне можете использовать такую трактовку. Здесь же, на данном форуме, использование такого рода лексики и подхода к правописанию приравнивается к банальной безграмотности и штрафуется соответствующим образом (об этом объявлялось публично, могу поискать).
Димитрий, Вам, кажется, вполне однозначно дали понять, как люди относятся к обилию ошибок. Вы почему-то сочли это "переходом на личности", а зря - перечитайте тему, тут много ценных высказываний для Вашего "маркетингового исследования" :)
atmarozak, добрый совет: программиста проще найти в разделе "Работа для веб-мастера". Только с правилами раздела ознакомьтесь. И не используйте больше красные буковки, у Вас некрасиво получается :)
А давайте Вы с этим разберётесь как-нибудь побыстрее, и нам расскажете, с подробностями. Иначе не могу ручаться за сохранность данного топика.
В бан его отправили не из-за того, что скрипт нуленый (я в это не верю), а за клоноводство. Вас попрошу быть сдержанней в выражениях, иначе буду штрафовать. Мат "под звездочками" - это тоже мат.
Тему закрываю за отсутствием ТС.
Вот, изыскания ашмановцев на эту тему. Там "средняя температура по больнице", со всеми вытекающими.
Например, график распределения вероятности клика по позициям, на данные Кости мало похож :)
Видимо, да. А это сугубо их терминологическое изобретение?
Зато там очень неудобный INSERT и перенос веток. Поэтому я использую не одно большое дерево, а "лес" - в этом хитрость.
Если операции изменения БД централизовать в каком-то одном специальном классе - этот код достаточно написать один раз, оттестировать как следует, и больше не задумываться о нем.
Ладно, я пойду бухать корпоратив и придумывать каверзные контраргументы, завтра Вас еще потерзаю :) Спасибо за интересную дискуссию.
AndreM, а, вот тут-то мы и добрались до самого интересного, бишь до кеширования. Тогда внимание вопрос: если мы кэшируем дерево целиком, нам не пофигу, как его выбирать? Хоть тыщей запросов :) И еще вопрос: а зачем кэшировать промежуточно-абстрактное "дерево целиком", если можно закешировать результаты?
Насчет зависающих процессов - это надо смотреть на Вашу конкретную систему. Убейте, не пойму, где должен повиснуть запрос, достающий 1 запись по primary :)
ОК, а как Вы решаете задачу поиска в категории?
timur-kar, да, именно так. Ну, с небольшими хитростями.
timur-kar, для таких вещей как раз придумали Nested Sets. На такой структуре, очевидно, придется найти все айдишники подветвей и делать WHERE parent_id IN (1, 2, 3...). Подветви выбираем либо по схеме "раскрытое меню до текущей категории", либо последовательностью запросов с WHERE parent_id IN (...) по числу уровней. Но это действительно тяжелая штука. Я в итоге все-таки добавил nested sets специально под это.
Ну, формулируя задачу "как в учебнике" Вы рискуете нарваться на копипаст ответа из учебника, а это неспортивно :)
Так что я кое-что уточню, а Вы поправьте. Во-первых, ограничим вложенность 5 уровнями (больше редко бывает, по крайней мере на 1000 категорий). Во-вторых, предположим относительно равномерное распределение подкатегорий.
Так вроде структура, которую Вы описали - и есть связанные списки (списки смежности, Adjacency List).
Полное дерево получается запросом "SELECT * FROM tree", и далее какой-то такой ахтунг. Про "селект поиска" не понял.
Выбираем текущую запись, добавляем в массив. Если родитель - не корень, выбираем родителя, добавляем в массив. Если не корень... и т.д.
Как Вы думаете, что эффективней: 5 запросов по primary key, или 5 джойнов таблицы на саму себя? А что доступней для понимания?
Получаем путь, далее идем по уровням, начиная с корня, если узел есть в пути - уходим в рекурсию. Соответственно, еще 5 очень легких запросов.
Не понял. SELECT name FROM tree WHERE id = 22?
Критикуйте :) Вариант с 1.500.000 записей не предлагать. Сами сказали, что их тыща :)
Про "индусский стиль" ничего не хочу слышать.
А у нас mysql4 :(
