Лишние join в SQL запросах

[kozzztik]

да, собственно именно parent у меня и дает всю тяжесть, Что характерно, если NULL нет, а идет сравнение с числовым значением по ID, то при обращении по parent_id никаких проблем нет.

[magic4x]

Вот это да. Не знал, спасибо.
Удалось вот так:

Category.objects.extra(where=['parent_id IS NULL'])

SELECT `category`.`id`, ... FROM `category` WHERE parent_id IS NULL ORDER BY `category`.`tree_id` ASC, `category`.`lft` ASC

[webus]

Ребзя! ORM зло. Ее можно использовать на небольших проектах, аля бложик и т.д. куда идеально ложится модель Active Record. Если у вас проектирование идет от данных, т.е. схема БД проектируется более тщательно, то тут ORM не прокатит.

[gleb_kudr]

Вы только что сказали что-то типа: «Пацаны, ООП зло, оно используется только для небольших проектов, гостевухи там всякие, а на большие проекты вы код проектируете более тщательно, там нужно только ассемблер, только хардкор!»

На ОРМ надейся, а сам не плошай — так лучше будет.

[webus]

Это я и хотел донести)

[webus]

Я тоже видел большие проекты на том же Hibernate (Java). И что толку. Около 5000 таблиц, база под 300 Гб. Практически над каждым действием орм написан ручной запрос, потому что сам Hibernate генерирует такую портянку что ваш DBA вас просто повесит. В итоге в таких проектах смысл использования ORM сводится только ради использования ORM. Т.к. все запросы все равно переписаны вручную.

[kozzztik]

Вообще то нет. Не скажу за Hibernate, но занимался исследованием эффективности запросов — и они вполне себе ничего.
И мне вот интересно что вы будете делать с «внезапным» переездом проекта с MySQL на SQLLite.Счастливой отладки без ORM.

Я уж молчу о том, что свобода от написания JOIN очень сильно облегчает процесс разработки когда ты и жнец и швец и на дуде игрец. Не буду считать на столько быстрее написать parent__plugin_id чем делать JOIN таблицы самой к себе и проверки поля вручную.

Django кстати говоря крайне удобен тем, что вы не обязаны использовать его целиком. Если вам не нравятся его модели, вы можете вообще ими не пользоваться, при этом все остальное будет работать так же.

[StraNNikk]

Спасибо за заметку! От себя могу добавить ещё одну особенность — при удалении объектов через ORM когда мы пишем

SomeModel.objects.filter(...).delete()

Django почему-то сначала делает SELECT и выбирает все записи, которые соответствуют условию, указанному в filter, а уже потом только DELETE. То есть как RAW SQL это выглядит примерно как-то так:

SELECT "some_table"."id", ... FROM "some_table" WHERE ...
DELETE FROM "some_table" WHERE "some_table"."id" IN (...)

Причем в результатах выборки первого SELECT присутствуют все поля, а не только поле primary key.
Наверное, создатели движка хотели таким образом предусмотреть какую-то исключительную ситуацию, но вообще говоря в большинстве-то случаев первый SELECT казалось бы лишний.

[Sardar]

На каждый обьект джанга кидает pre_delete, post_delete, от этого зависит много логики. Поэтому такая выборка и поэтому со всеми полями. Но да, хотелось бы видеть:

SomeModel.objects.filter(...).delete(skip_signals=True)

[StraNNikk]

Точно! Совсем запамятовал про сигналы… теперь все встает на свои места.

[kozzztik]

Еще не вникал в тему, но читал что при таком удалении сигналы не генерируются. По крайней мере delete обработчик модели не вызывается. В мануале советуют удалять по одной.

[homm]

Дак вникните, откройте документацию по сигналам. Хотя согласен, что в описании QuerySet.delete() стоило бы и о сигналах написать.

[kozzztik]

Тогда не понятно, что же им помешало вызвать delete обработчик модели, ежели они все равно их выбирают.

[Sardar]

Если удалять через object.delete(), то будет по одному запросу на каждый обьект. Джанга умно собирает все суб-дерево удаляемых обьектов, вместе с их ForeignKey зависимостями, затем удаляет все через несколько batch delete запросов. Так гораздо эффективней. Почитать можно в django.db.models.deletion

[pawnhearts]

Есть ещё такой момент — django, по-умолчанию, удаляет связанные объекты, причем на уровне приложения, а не sql(sqlite, afaik, не поддерживает delete cascade)

[Honeyman]

А что EXPLAIN говорит? А то (особенно с учётом фичи join removal в PostgreSQL 9.0) это может оказаться не такой уж и проблемой…

[kozzztik]

А что может сказать EXPLAIN? Что вопрос плохо составлен? Это и так очевидно. Про PostgreSQL не знаю, я им не пользуюсь. У меня везде MySQL при том не самый свежий.

[petropavel]

в MariaDB тоже есть «join removal» — только называется по другому, table elimination.

Но тут дело в другом. Сам запрос-то правильный? А то мне кажется, что нет. То есть, я не знаю, что надо получить, но запрос с join-ами явно не эквивалентен запросу с WHERE parent_id IS NULL. Так что join-ы там по-любому не лишние. С точки зрения DBMS. И никто их автоматически не уберет.

Хотя там, наверно, ORM свои дополнительные условия накладывает, при учете которых запросы становятся эквивалентными, так?

[kozzztik]

Конечно неправильный. Об этом то и статья, если вы не заметили. Об избыточных Join которые совсем не нужны.

[petropavel]

Я имел в виду, что «неправильный» в смысле, дает некорректный результат. А «добавляет избыточный join» — это я воспринимаю как «напрасно усложняет запрос, но результат остается правильный».

То есть для меня «неправильный ответ» — это все-таки гораздо более сильная степень «неправильности», чем просто «работает дольше, чем нужно».

[kozzztik]

Это я вам и без Explain скажу. В нормальных условиях возвращает правильный результат. Но эти join именно избыточны и увеличиваю время исполнения на порядок. А лишние 100-200мс при формировании страницы вполне может оказаться критичной проблемой.