Да, индекс a,b,c также не будет использован при запросе типа WHERE b=:b.
А вообще — не надо меня слушать и верить мне. А надо почитать маны MySQL по индексам.
MySQL использует многостолбцовые индексы таким образом, что запросы выполняются быстро, когда указывается известная часть для первого столбца в индексе в выражении WHERE, даже если не заданы величины для других столбцов.
Где-то я читал, что это справедливо не только для 1 столбца, но для любого количества первых (левых) столбцов индекса. Т.е. составной индекс на три поля a,b,c может использоваться на запросах WHERE a=:a, WHERE a=:a AND b=:b еtс. Но не может быть использован на запросах WHERE c=:c
Это значит, что ключ parent_id_i прибивать нельзя ни в коем случае! Я наоборот предложил его расширить. Но это нужно перепроверять — достаточно ли сферичны Ваши запросы, чтобы это имело смысл
По поводу сортировки по tiltle для NS — использовать такой запрос мешает:
— поломанная сортировка по leftKey — условие для вывода развернутого дерева (там же рекурсия, ёпт :)
— отсутствие уверенности, что MySQL обработает такие вложенные запросы быстрее, чем php отсортирует массив
Да и зачем здесь вообще вложенный запрос? только ради сортировки? так ее можно было бы указать и во внутреннем запросе. Но все равно, на выводящую функцию данные должны выводиться отсортированные по leftKey, иначе дерево за один проход не построишь
SELECT takoi VERY slozhnii select
если грубо — то SELECT * FROM tree WHERE leftKey > :lk AND rightKey < :rk ORDER BY leftKey
Автор статьи прав. Мы, PHP-оиды, живем с шорами на глазах. Как именно оно там работает и что происходит — хз.
Создаем виртуальный хост, index.php — в корень. И поехали.
А тут предложена реализация, годная и для production в том числе.
PHP не предназначен для построения графиков функций. MathCad (octava) — предназначен. Почему бы не использовать инструменты по назначению? Потому что программеры не поймут? Так они такими темпами никогда и ничего не поймут и ничему не научатся. Брось PHP-оида в проект на рельсах — и посмотри что получится. Утонет — увольняй. Выплывет — поднимай зарплату и грузи дальше. И будет у тебя под руками не тупой PHP-шник, а нормальный многогранный WEB-программер.
А можно пример — какой хостер не поддерживает хранимые процедуры. Я правильно понимаю что это возможно только в том случае, когда MySQL старше 5-й версии?
Абсолютно с Вами согласен!
У меня просто очередная «детская травма» — я на данный момент работаю над проектом, в котором под лозунгом «MySQL — это не реляционная СУБД» все таблицы необоснованно денормализованы (никто не проводил никакого профайлинга). И тем не менее, запросы остаются сложными, имеют вложенные подзапросы и несколько JOIN. А проект получился плохо расширяемым и поддерживаемым.
Параллельно второй проект (намного более нагруженный) с нормализованной базой (форму не скажу, но дублирования связей я все-таки избежал) и аккуратно проставленными индексами крутится себе и горя не знает. Расширяется и поддерживается легко и приятно.
Именно поэтому для меня лично необоснованная денормализация вызывает внутренний протест
Кеш — это просто замечательно, кеш — это правильная денормализация. Но тогда необходимо выполнить еще несколько телодвижений
Таблицу в heap.
Для каждой записи указать expires.
Таблицу пересчитывать на лету.
И, естественно, для каждого телодвижения перепроверить — не дорогой ли кеш получится?
я бы предложил во время пересчета таблицы добавлять не по одной строке, а блоком по 20-100 строк. Где-то я читал, что в этом случае индексы пересчитываются чуть быстрее. Массив для вставки придется накапливать в памяти, но мне кажется он не очень тяжелый. Как альтернатива — можно отключать индексы (сам не пробовал, только читал)
Еще я бы внимательно пересмотрел индексы таблицы `pages_paths`.
1. Ключ `item_id_i` такой как он есть сейчас не нужен — MySQL прекрасно подхватит его из составного ключа `item_id_u`
2. Ключ `parent_id_i` я бы сделал составным (добавил поле item_id справа). Есть легенда, что в таком случае на некоторых сферических запросах в вакууме значения item_id при выборке будут браться прямо из ключа.
3. Почему Вы не проиндексировали поля, используемые для сортировок?
Естественно, вся эта оптимизация должна идти под постоянным контролем EXPLAIN на наиболее часто используемые запросы.
Да, и у Вашего решения есть 1 несомненный + — очень просто сделать выборку раскрытого по некоторой ветке иерархического дерева с сортировкой внутри уровня по названию page.title. В том же Nested Set, к примеру, приходится ручками перебирать.
Знаете что? Мне не нравится ваша модель. Но это скорее всего моя проблема — мне не нравится ни одна из моделей хранения иерархических структур в реляционных БД. ( Мне не нравится этот корабль, мне не нравятся эти матросы, мне вообще ничего не нравится!)
Чуть меньше остальных лично мне не нравится структура Nested Sets. С ней действительно «непонятно» работать руками. И не нужно! Я заставил ее работать через Zend_Db_Tree. Где-то здесь видел реализацию от Doctrine.
Да, кстати, Вы забыли упомянуть что внешние ключи (а вернее, каскадное удаление по внешнему ключу) в MySQL срабатывают только при engine=«InnoDB». Как минимум, это потеря полнотекстовых индексов.
И еще: добавление такой таблицы — это денормализация базы, что не всегда есть хорошо. Делай хорошо, а плохо само получится!
А ведь красавцы! Сначала новость немного исправили — не «мы тупим и держим все в открытом доступе», а «хакеры взломали», а теперь можно смело опровергать — «да не было там ничего такого секретного», дальше ждем «была задержана группа хакеров, взломавших сервер МВД»
Нашел одну ссылочку, если кому интересно. Действительно видел такую ошибку на сайтах, использующих Apache (думал, что проблема из-за cgi, а тут описана такая же ошибка при использовании basepath). Опять — таки нужно будет поиграться и применить.
На ноде ничего сложного не писал, но в браузерном скрипте к асинхронности привык за 1 проект, даже иногда хочется что-то такое в PHP увидеть.Чем вам асинхронность не угодила? Сходил по ссылке на async, посмотрел примеры, качаю, посмотрю как реализовано. Спасибо
Согласен на 100%. Поизобретать все-таки прийдется — у меня скрипт по ссылке не отрабатывает в NetBeans и skype. Специально проверил — в этих приложениях не работает копипаст через primary-буфер (выделение текста вместо Ctrl+C, средняя кнопка мыши вместо Ctrl+V)
А вообще — не надо меня слушать и верить мне. А надо почитать маны MySQL по индексам.
Не совсем так. Здесь сказано:
Где-то я читал, что это справедливо не только для 1 столбца, но для любого количества первых (левых) столбцов индекса. Т.е. составной индекс на три поля a,b,c может использоваться на запросах WHERE a=:a, WHERE a=:a AND b=:b еtс. Но не может быть использован на запросах WHERE c=:c
Это значит, что ключ parent_id_i прибивать нельзя ни в коем случае! Я наоборот предложил его расширить. Но это нужно перепроверять — достаточно ли сферичны Ваши запросы, чтобы это имело смысл
По поводу сортировки по tiltle для NS — использовать такой запрос мешает:
— поломанная сортировка по leftKey — условие для вывода развернутого дерева (там же рекурсия, ёпт :)
— отсутствие уверенности, что MySQL обработает такие вложенные запросы быстрее, чем php отсортирует массив
Да и зачем здесь вообще вложенный запрос? только ради сортировки? так ее можно было бы указать и во внутреннем запросе. Но все равно, на выводящую функцию данные должны выводиться отсортированные по leftKey, иначе дерево за один проход не построишь
если грубо — то SELECT * FROM tree WHERE leftKey > :lk AND rightKey < :rk ORDER BY leftKey
Создаем виртуальный хост, index.php — в корень. И поехали.
А тут предложена реализация, годная и для production в том числе.
PHP не предназначен для построения графиков функций. MathCad (octava) — предназначен. Почему бы не использовать инструменты по назначению? Потому что программеры не поймут? Так они такими темпами никогда и ничего не поймут и ничему не научатся. Брось PHP-оида в проект на рельсах — и посмотри что получится. Утонет — увольняй. Выплывет — поднимай зарплату и грузи дальше. И будет у тебя под руками не тупой PHP-шник, а нормальный многогранный WEB-программер.
Ушел писать сайт на bash.
У меня просто очередная «детская травма» — я на данный момент работаю над проектом, в котором под лозунгом «MySQL — это не реляционная СУБД» все таблицы необоснованно денормализованы (никто не проводил никакого профайлинга). И тем не менее, запросы остаются сложными, имеют вложенные подзапросы и несколько JOIN. А проект получился плохо расширяемым и поддерживаемым.
Параллельно второй проект (намного более нагруженный) с нормализованной базой (форму не скажу, но дублирования связей я все-таки избежал) и аккуратно проставленными индексами крутится себе и горя не знает. Расширяется и поддерживается легко и приятно.
Именно поэтому для меня лично необоснованная денормализация вызывает внутренний протест
Таблицу в heap.
Для каждой записи указать expires.
Таблицу пересчитывать на лету.
И, естественно, для каждого телодвижения перепроверить — не дорогой ли кеш получится?
я бы предложил во время пересчета таблицы добавлять не по одной строке, а блоком по 20-100 строк. Где-то я читал, что в этом случае индексы пересчитываются чуть быстрее. Массив для вставки придется накапливать в памяти, но мне кажется он не очень тяжелый. Как альтернатива — можно отключать индексы (сам не пробовал, только читал)
Еще я бы внимательно пересмотрел индексы таблицы `pages_paths`.
1. Ключ `item_id_i` такой как он есть сейчас не нужен — MySQL прекрасно подхватит его из составного ключа `item_id_u`
2. Ключ `parent_id_i` я бы сделал составным (добавил поле item_id справа). Есть легенда, что в таком случае на некоторых сферических запросах в вакууме значения item_id при выборке будут браться прямо из ключа.
3. Почему Вы не проиндексировали поля, используемые для сортировок?
Естественно, вся эта оптимизация должна идти под постоянным контролем EXPLAIN на наиболее часто используемые запросы.
Да, и у Вашего решения есть 1 несомненный + — очень просто сделать выборку раскрытого по некоторой ветке иерархического дерева с сортировкой внутри уровня по названию page.title. В том же Nested Set, к примеру, приходится ручками перебирать.
Чуть меньше остальных лично мне не нравится структура Nested Sets. С ней действительно «непонятно» работать руками. И не нужно! Я заставил ее работать через Zend_Db_Tree. Где-то здесь видел реализацию от Doctrine.
Да, кстати, Вы забыли упомянуть что внешние ключи (а вернее, каскадное удаление по внешнему ключу) в MySQL срабатывают только при engine=«InnoDB». Как минимум, это потеря полнотекстовых индексов.
И еще: добавление такой таблицы — это денормализация базы, что не всегда есть хорошо. Делай хорошо, а плохо само получится!
Никто не в курсе — в Одессе что-то подобное планируется?
У меня никто никуда сам без спросу не лезет обновляться.
kryoz, спасибо, натолкнули на решение.