Могу. Но он будет неэффективный.
07.12.2022, 23:43
Т. Е. Не очень можешь
Порой? Всегда.
Помню как-то начальник начальника пришёл ко мне и начал спрашивать ,почему они не получают значения учёта нового продукта, который запустили на прошлой неделе. Было забавно, ведь ни я, и даже мой непосредственный начальник, не были в курсе, что они вообще что-то новое запускали.
Как обычно, директор что-то решил, дали срок месяц и пустили всё по цепочке вниз. Каждое звено отжирало неделю на перекладывание всяких бумажек и планирование ахуенных работ. А потом приходят к тебе и "ты ещё неделю назад должен сделать вот это".
Как обычно, директор что-то решил, дали срок месяц и пустили всё по цепочке вниз. Каждое звено отжирало неделю на перекладывание всяких бумажек и планирование ахуенных работ. А потом приходят к тебе и "ты ещё неделю назад должен сделать вот это".
Ага, с джавой.
Так на собеседовании и скажут.
нет никаких эффективных запросов. Есть оптимизированные запросы, а задача оптимизации - это не "пальцем в небо" и не "у меня высокая экспертиза, я могу написать", а банальный поиск оптимума... а в этом машина безусловно превосходит человека. Так что больше на "приколы для даунов" смахивает.
"Приколы для эффективных менеджеров"
ну так а машину, которая составляет план, кто пишет? А? А? Конечно, мы же помним про энтропию Шеннона - если человек созадет алгоритмическую машину, то именно он и вкладывает в нее информацию, поэтому машина на уровне "уметь все" человека не превосходит... но на уровне той алгоритмической задачи, которая ей поставлена, с учетмо кол-ва информации, заложенной программистом - в разы, в десятки раз, в сотни.
машина может тупо следовать инструкциям и иногда сама себя может перехитрить, особенно когда ей начинают сильно усложнять эти инструкции, этот поиск оптиума тоже пишется несовершенными людьми
приведу пример в 19ом оракле на основе сбора статистки по таблице оракл может перестраивать план запроса по щучьему велению
и когда в таблице 100 записей или пара миллионов это большая разница и этот перестроенный план может выстрелить в ногу
приходится хинтовать свои скрипты и прибивать свой план запроса гвоздями
приведу пример в 19ом оракле на основе сбора статистки по таблице оракл может перестраивать план запроса по щучьему велению
и когда в таблице 100 записей или пара миллионов это большая разница и этот перестроенный план может выстрелить в ногу
приходится хинтовать свои скрипты и прибивать свой план запроса гвоздями
Хаха, если бы.
Оптимизаторы нынче неплохи, но перестраивать целиком структуру запроса, что порой приводит к оптимизации порядков на 5, не умеет.
Как и анализировать не структуру, а непосредственно суть данных, чтобы поменять запрос, более оптимальный для конкретных данных именно вот в этой таблице именно сейчас.
Оптимизаторы нынче неплохи, но перестраивать целиком структуру запроса, что порой приводит к оптимизации порядков на 5, не умеет.
Как и анализировать не структуру, а непосредственно суть данных, чтобы поменять запрос, более оптимальный для конкретных данных именно вот в этой таблице именно сейчас.
мы же понимаем ,что в исходном "меме" ни слова про оптимизацию структуры запроса, а про "написание эффективного sql-запроса". Машина может написать "эффективный sql-запрос" просто потому что в принципе декларативный язык допускает оптимизаионный поиск.
А вы мне все пытаететсь рассказать про то как сейчас линейно устроена планирование запроса на уровне БД. Ну ок, так то еще в 60-х изобреталось :)
А вы мне все пытаететсь рассказать про то как сейчас линейно устроена планирование запроса на уровне БД. Ну ок, так то еще в 60-х изобреталось :)
use the index, Luke. Маркус Винрад очень доходчиво объясняет
Спасибо, да, индекс - хорошая вещь. Настолько, что у меня в базе есть таблица с парой миллионов строк и 50 столбцами, и на 80% она состоит из индексов. Прямые запросы к ней - ок бро, но стоит делать join‘ы с другой таблицей или, упаси боже, вставленные SELECT’ы в запросе/модификации - и оракл говорит: «я буду это делать 20 минут (хотя, стоимость исчисляет десятками тысяч операций, что по идее должно длиться секунды), за это время успеешь несколько раз сходить нахуй».
Разбирал по кирпичикам, проблема стреляет именно с join’ами
Разбирал по кирпичикам, проблема стреляет именно с join’ами
Не всегда решение в индексах или performance tuning'е самой бд, иногда приходится денормализировать таблицы или использовать clustered таблицы. От дисковой подсистемы опять же многое зависит. В идеале чтобы БД была на SSD и не на copy-on-write файловой системе.
Короче вопросы по БД это такая вещь где в общих чертах можно много чего посоветовать, но для дельных советов надо знать и структуру БД и запросы которые тормозят.
Короче вопросы по БД это такая вещь где в общих чертах можно много чего посоветовать, но для дельных советов надо знать и структуру БД и запросы которые тормозят.
Собесы это вообще отдельная боль. У тебя может быть проект на гитхабе с тысячей звезд, который о твоих способностях говорит больше, чем любые вопросы, но вместо того чтобы слегка отойти от стандартного процесса и зайти к тебе на гитхаб тебе все равно будут трахать мозг какими-то базовыми вопросами ответить на которые ты не можешь банально потому что либо делаешь это на подсознательном уровне, либо какими-то терминами за свою практику ты не пользовался даже если используешь это каждый день.
Ты удивишься, но...
Например, в колоночной распределенной базе, обычный column scan работает чаще всего быстрее, чем индекс. О чём, впрочем, прямо написано в документации, и почему так - тоже.
Так что не бывает универсальных советов, тем более, что индексы ебать как не бесплатны, если у тебя данные насираются миллионами строк в минуту.
Например, в колоночной распределенной базе, обычный column scan работает чаще всего быстрее, чем индекс. О чём, впрочем, прямо написано в документации, и почему так - тоже.
Так что не бывает универсальных советов, тем более, что индексы ебать как не бесплатны, если у тебя данные насираются миллионами строк в минуту.
Так он и интересуется потому что не может и хочет чтобы ии писал запросы, машина быдляцкая
Select MyTable.dbo (mycolumn1, mycolumn2)
Ну на самом деле возможно уже и может: https://habr.com/ru/post/703380/
Напишу, может, и не самый эффективный, но уж точно эффективнее, чем его генерят некоторые фреймворки.
Чтобы написать коммент, необходимо залогиниться
