Какие вилки зарплат у sql'щиков?

И разработчик c++ пользует «готовый продукт» в виде ide, конпеляторов, ос и компьютеров. Он не занимается проектированием cpu а только пользует его.
Мне кажется до таких абстракций не стоит доходить.

Не, на самом деле им «кажется просто и правильно» свалить работу на другого, но им не дают этого сделать. :)

Это отдельная тема :)

mssql, postgresql

Где ракл, кстати?

О, коммуниста сразу видно

ТС одну s с y перепутал :)

Блин, как же цитат не хватает!!!

Ну тут ты или знаешь оконные функции, или не знаешь.

LAG, RANK

Из-за ограниченности MS SQL местами - постоянно используются для BI дашбордов.

Там через следующее/предыдущее значение и последующие агрегации
но в продакшон такое не годится совершенно

И что в этом плохого? Ну, если по периоду ограничивать, чтобы ВСЁ запросом не озадачить...

Это DBA, по сути, там ещё сервак администрировать, ядро крутить, вот это всё... При этом особо SQL запросы, модели данных придумывать не надо.

Унижение - основа управления. Можно полапать специалиста, например.

Что, лапает 67-летний начальник, а ты молчишь за зарплату? )

И что в этом плохого?

То, что это НАМНОГО более ресурснозатрано, чем просто пройтись по выходному набору. Это не ограничивается микрозадачкой никогда и потом эти ваши портянки деоптимизируюся, тормозят и воняют, потому что никто не хочет и не может их трогать. У нас, к слову, дохера таких скуэль отчётов на 1к строк, их просто не трогают, потому что тронешь оно рассыпется, где-нибудь выдаст что-то кроме скаляра, не тот скаляр, в итоге бухгалтерия не пойдёт и нам будут сношать целый месяц мозги из-за девяти рублей. А юзеры сидят, добавьте колонку, ну позязя.

ЕМНИП это из MSSQL всё пошло - там оптимизатор зашибись делает.
Так то я за временные таблицы - читать всем легче...

там оптимизатор зашибись делает

Кто-то на внезапную деоптимизацию не нарывался просто. Когда софт пытается быть умнее того, кто его использует, это всегда заканчивается в говне. Да и не сделает оптимизатор тебе оконную функцию с подзапросом быстрее тупого прохода.

не сделает оптимизатор тебе оконную функцию с подзапросом быстрее тупого прохода

А можете с цифрами?

Вот по мотивам той задачи тестовая таблица на ~4M записей:

CREATE UNLOGGED TABLE t_test_data AS
WITH RECURSIVE tgen(fts, fval) AS (
    VALUES (now()::timestamp, 0)
  UNION ALL
    SELECT fts + interval'1m', round(random())::int
    FROM tgen
    WHERE fts < '2030-01-01'
)
SELECT to_char(fts, 'yyyy-mm-dd HH24:MI') AS fdate, fval FROM tgen;

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

У меня сейчас есть два варианта на оконных функциях. И они различаются по скорости в ~4 раза (около 24 секунд на коде от лидера против около 84 секунд на моем собственном выстраданном коде на оконках - всё на дачной, слабенькой машинке). Т.е. тут как бы два вывода: 1) оконки не магия ими тоже надо уметь пользоваться 2) в общем-то наглядный показатель почему наши с ним зарплаты должны отличаться в ~4 раза.

Можете дать свой код на чем угодно? Запущу на этой же дачной машинке.

let arr = [];
for (let i = 0; i < 4_000_000; i++) {
    arr.push({i, val : +(Math.random() > 0.5), streak : 0});
}
let start = new Date().getTime();
let streak = 0, len = arr.length;
let stack = [];
for (let i = 0; i < len; i++) {
    let rec = arr[i];
    if (!rec.val) {
        if (stack.length) {
            stack.forEach(v=>v.streak = streak);
            stack = [];
        }
        streak = 0;
    } else {
        ++streak;
        stack.push(rec);
    }
}
let time = new Date().getTime() - start;
time //161 ms

> arr
[
  { i: 0, val: 1, streak: 1 },
  { i: 1, val: 0, streak: 0 },
  { i: 2, val: 1, streak: 2 },
  { i: 3, val: 1, streak: 2 },
  { i: 4, val: 0, streak: 0 },
  { i: 5, val: 0, streak: 0 },
  { i: 6, val: 0, streak: 0 },
  { i: 7, val: 0, streak: 0 },
  { i: 8, val: 0, streak: 0 },
  { i: 9, val: 1, streak: 1 },
  { i: 10, val: 0, streak: 0 },
  { i: 11, val: 0, streak: 0 },
  { i: 12, val: 0, streak: 0 },
  { i: 13, val: 0, streak: 0 },
  { i: 14, val: 0, streak: 0 },
  { i: 15, val: 0, streak: 0 },
  { i: 16, val: 0, streak: 0 },
  { i: 17, val: 1, streak: 2 },
  { i: 18, val: 1, streak: 2 },
  { i: 19, val: 0, streak: 0 },
  { i: 20, val: 0, streak: 0 },
  { i: 21, val: 0, streak: 0 },
  { i: 22, val: 0, streak: 0 },
  { i: 23, val: 0, streak: 0 },
  { i: 24, val: 1, streak: 1 },
  { i: 25, val: 0, streak: 0 },
  { i: 26, val: 1, streak: 2 },
  { i: 27, val: 1, streak: 2 },
  { i: 28, val: 0, streak: 0 },
  { i: 29, val: 1, streak: 5 },
  { i: 30, val: 1, streak: 5 },
  { i: 31, val: 1, streak: 5 },
  { i: 32, val: 1, streak: 5 },
  { i: 33, val: 1, streak: 5 }
...

cat /proc/cpuinfo | grep "model name"
model name	: Intel(R) Core(TM) i3-6300 CPU @ 3.80GHz

На сортировку ушло секунд 5 после перемешивания массива рандомом, для более-менее отсортированного массива быстрее. То есть в худшем случае оно отработает в ~5 раз быстрее, чем в самом извёрнутом случае на sql. Если взять во внимание сопровождаемость sql портянок, то спорить тут особо не о чём.

Не, это не честно. Но мысль понял. Спасибо.

Вечером после работы попробую поиграть в ваш вариант.

Только по-честному - с выдергиванием таблицы из БД и впихиванием результата обратно.

Только по-честному - с выдергиванием таблицы из БД и впихиванием результата обратно.

Извините, когда делается выборка кто-то впихивает результат обратно в таблицу?
Это во-первых. Во-вторых, а нахера, извините, в таблице нужно такое поле? Вы хотите покласть писюн на нф?

Не обязательно же в физическую таблицу. Просто эта выборка гипотетически может быть основой для внешней выборки. SELECT FROM (SELECT мы-тут). Оно же не уточняется зачем нам приспичило считать серии. Маловероятно что они сами по себе какую-то ценность несут в голом виде. Наверняка где-то дальше должны использоваться в прикладной задаче. Значит надо вернуть так или иначе.

Мне так кажется.

Значит надо вернуть так или иначе.

Кому надо? Можно и на 3-м звене делать что-то там, что делают обычно на вложенках. Привариваться к субд намертво совсем не обязательно в подавляющем большинстве задач.

Кто-то на внезапную деоптимизацию не нарывался просто.

это что за гомноСУБД?

Оракл же. А что тебя удивляет? Автоматический оптимизатор по-другому работать не будет. В 98% всё ок, в 2% сделает херню. Не нравится, use hints, Luke.

Между

внезапную деоптимизацию

и тем, что оптимизатор не осиливает оптимизацию с самого начала есть разница.

и тем, что оптимизатор не осиливает оптимизацию с самого начала есть разница.

Лучше бы он её или осиливал, или не осиливал и работал однообразно. Но в реальности оказалось не всё так радужно и из-а того, что кто-то хочет быть умнее, чем надо, перед новым годом пришлось с мыльной жопой переделывать довольно вредный кусок кода.

Лучше бы он её или осиливал, или не осиливал и работал однообразно.

Открою тебе страшную тайну - Оракл работает однообразно.

А у каждого проишествия есть имя, фамилия и должность.

На моей памяти было пара подобных инцендентов и каждый раз торчали уши ДБА. Один раз сервер работал без статистики и тут ДБА спохватился и решил посчитать статистику, что поставило раком запросы. Другой раз (уже другой ДБА) сделал пересчет статистики как-то криво и оная исчезла.

Вожможно ваш ДБА что-то вам говорит про то что оракл гогно, не спорю.

А у каждого проишествия есть имя, фамилия и должность.

У нас нет дба как такового, там никто ничего не делал. Вот так вышло, что накопилась статистика и один запрос стал работать вместо 2 сек. 5 минут и требовать подпорок хинтами.

У нас нет дба как такового, там никто ничего не делал.

Вот в этом и проблема, а всё остальное - твои домыслы из-за непонимания, как работает CBO в Оракле.

Ну так. Священный ракл же не может работать через жопу.

У рукожопов любой софт заработает через жопу.

Я всю жизнь SQL старательно избегал, а недавно с удивлением услышал, как кто-то на ютубе произносит его не как «эс-кью-эль», а как «сиквел». Это общепринятое произношение?

Шо поделать, других спецов у нас нет.

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