Меню
Что нового?

Свой cron с проверкой в 3-5 сек

fixxxer написал(а):
Представь себе, даже тут можно обделаться, имея хорошую фантазию. Я сам удивился, когда увидел. :)
Нажмите для раскрытия...
Полностью поддерживаю. Есть такой класс программистов - "я знаю SQL". И они будут все делать через SQL запросы, используя многоэтажные запросы с 2-3 уровнями вложенности. Хотя по факту вообще ничего не понимают что делают и считают что внутри базы все на магии работает. Кстати отчасти из-за таких разработчиков бытует мнение что база это самое узкое место в стандартном пхп приложении.
 
@Valick Это был сарказм. Это был пост о тех которые думают что они знают SQL (хотя это не так). Знать синтаксис не значит понимать как это работает и понимать когда применять один сложный запрос, а когда лучше 100500 мелких.
И под многоэтажными запросами я подразумевал запросы именно с вложенными подзапросами и так несколько уровней вложенности. Надеюсь не стоит объяснять что шанс что они будут работать быстро и оптимально - минимален. И джоины к этому не имеют никакого отношения.
 
@Valick Трудно сейчас с головы придумать такой subquery. Я такой треш не храню. Я вот даже специально не могу такой треш придумать. А реальность оказалась значительно суровее.

Но вот что точно помню, на практике было когда различные сабквери одновременно в одном запросе были:
- в where, включая вычисления с результатом этого сабквери
- в from
- в join
И в добавок эти сабквери имели свои сабквери. Сейчас тот треш показать не могу т.к. за долгое время все-таки было исправлено. Но если очень приблизительно, то там в реальном времени высчитывалось куча средних значений (т.е. различные функции агрегации для получения уникального числа) из разных таблиц на пару лямов записей и эти коэффициенты использовались в условиях и расчетах для where и join. Мускуль не настолько умный чтобы для такого сгенерить правильный план запроса. После исправления схемы БД и логики бекенда и исправления запросов суммарное время уменьшилось с 5-30сек для одного запроса, до 0.01сек в сумме для 3-4 запросов (что-то нужно хранить в базе, а не считать каждый раз, чтото делать 2-3-мя быстрыми запросами, а не колхозить сабквери)

P.S. Попробую поискать в логах медленных запросов на бекап сервере - если конечно они хранятся. Тогда будет реальный пример. Хотя шанс небольшой учитывая что это было больше года назад.
 
Хранить, а не считать, это уже проблемы архитектуры. В принципе любую нормальную идею можно довести до абсурда. Я хочу сказать, только то, что человек который "я знаю sql" хорошо ориентируется в выборе инструментов для решения задачи.
Но отчасти согласен с вами. Когда появились триггеры и хранимые процедуры, многие их совали куда только можно было засунуть.
Видимо старею, и не понял на счёт сарказма.
 
Потому и было в кавычках. А так понятно что крайность. И я как раз насчет того что хорошо знать синтаксис SQL совсем не означает хорошо уметь его применять и ориентироваться в выборе инструментов для решения задачи.
Еще раз повторюсь - я тоже раньше думал что обычно дно это когда на каждый чих лезут в базу. Оказалось бывает и обратная сторона, когда боязнь лишнего запроса к базе и когда для того чтобы уменьшить количество запросов городят 100 этажные запросы с несколькими уровнями вложенности, но зато все в 1 запросе. Хотя надо было просто подумать и изменить схему и подход к хранению данных и сделать 2-3 быстрых запроса. Но тут же думать надо. А еще что-то знать в придачу. А это слооожна :)
 
Как раз вчера обсуждали с @kvf77 запрос на вывод товаров из категории с сортировкой по названию, когда название вычисляется - оно может быть на одном из языков.
SQL: 
select
  case when ru.name != "" then ru.model_name else en.name end as model_name
from models
left join translations as en on en.model_id = models.model_id and en.lang = 'en'
left join translations as ru on ru.model_id = models.model_id and ru.lang = 'ru'
where category_id = 7
order by model_name asc
limit 20
Сортировка делается по full scan.
Если вычисление в case заменить на generated column, запрос сможет использовать индекс.
 
grigori написал(а):
Если вычисление в case заменить на generated column, запрос сможет использовать индекс.
Нажмите для раскрытия...
Хм, но это выглядит так, как будто язык из таблицы translations выбирается в зависимости от accept-language или иного источника данных о языке посетителя. Иначе зачем такая универсальная схема с translations?
 
Мотороллер не мой, предполагаю что исторически - универсальные решения создаются без причин.
Понятно, что generated column - это хардкод. С другой стороны, языки не так часто добавляются, можно создать по виртуальному столбцу на язык, если нормализовать эту key-value структуру или в many-to-many, или в плоскую таблицу со столбцом на язык.
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.
Сверху