User avatar

Пока выдалась свободная минутка между исправлением всех хардкодов, хочу обсудить как могла бы выглядеть краткая формула записи сложности SQL-запросов, чтобы можно было быстро и на птичьем языке обсуждать запросы, которые скажем делают два LEFT JOIN с двумя группированными подзапросами, с последующей сортировкой по вычисленной формуле и взятием лимита. ПРОПОУЗАЛ:

Comment

0: константный запрос

 ‎· псы в рапиде
Comment

1: извлечение строки по первичному ключу или уникальному индексу;

 ‎· псы в рапиде
Comment

N: извлечение набора строк по индексу (iNdex); N!: извлечение строк по неиндексируемому условию, скорее всего full-table-scan;

 ‎· псы в рапиде
Comment

G: GROUP BY; количество букв соответствует кол-ву группируемых полей: GG, GGG, etc.; если группировка происходит не по индексу, то добавляем восклицательный знак;

 ‎· псы в рапиде
Comment

S: сортировка, использующая хороший индекс; S!: сортировка, не использующая индекс;

 ‎· псы в рапиде
Comment

(...): подзапрос (тут возникает вопрос, что делать с подзапросами, эквивалентными джойнам, см. ниже);

 ‎· псы в рапиде
Comment

...@...: INNER JOIN; ...<...: LEFT JOIN; ...>...: RIGHT JOIN; джойны по хорошим условиям; добавляем восклицательный знак для плохих условий (всё что не попадает в ключи)

 ‎· псы в рапиде
Comment

L: лимит/оффсет;

 ‎· псы в рапиде
Comment

чё, всё что ли?

 ‎· псы в рапиде
Comment

having? outer join?

 ‎· Читал этот тред
Comment

У нас тут дозволяется только ALT RIGHT JOIN

 ‎· igors 14
Comment

@igors: давайте без лулзов плз.

 ‎· псы в рапиде
Comment

H: HAVING

 ‎· псы в рапиде
Comment

@@@: OUTER JOIN (я лично вообще по-моему его ни разу не видел)

 ‎· псы в рапиде
Comment

@eth0: спасибо.

 ‎· псы в рапиде
Comment

Попробуем записать запрос in question: [N<FG<FG]S!L

 ‎· псы в рапиде
Comment

F: полная выборка без условий;

 ‎· псы в рапиде
Comment

[...]: чтобы понятно было, к чему относятся G, S, L.

 ‎· псы в рапиде
Comment

Имеет смысл отдельно указывать запросы с частичными выборками и запросы типа EXIST?

 ‎· bardo calling
Comment

Использование дорогих функций?

 ‎· sober, steady, good provider
Comment

DISTINCT? (тж. аггрегации)

 ‎· sober, steady, good provider
Comment

@voldmar: а что имеется в виду под частичными выборками? Про EXIST хорошая тема, но это же просто подзапросы вида 1 или N?

 ‎· псы в рапиде
Comment

@markizko: а какие там дорогие?

 ‎· псы в рапиде
Comment

@markizko: кстати да, интересно насколько на практике DISTINCT дороже.

 ‎· псы в рапиде
Comment

@squadette: ну любая функция по строке, типа UPPER, оператор LIKE '%...%' и тому подобное может прямо сильно дорого оказаться

 ‎· sober, steady, good provider
Comment

@markizko: а, точно. я забыл, да. для этого есть N!

 ‎· псы в рапиде
Comment

Тьфу, от усталости написал это вместо partial indexes

 ‎· bardo calling
Comment

EXISTS, если я правильно понимаю, останавливается на первом найденном. То есть может быть от одного запроса и до беконечности. Вижу разницу с подзапросом только в том, что подзапрос должен целиком отработать, а EXISTS сразу остановится

 ‎· bardo calling
Comment

а как же любимец индусов, CROSS JOIN?

 ‎· фемтоморти
Comment

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

 ‎· яснополянская хлеборезка
Comment

ну, и в интерактивных приложениях, по-моему, есть пан или пропал -- либо тебе удаётся сделать query так, что время исполнения это функция от размера запрошенной человеком страницы, а не от числа записей в базе, либо все кончено. другими словами, либо ты понимаешь как LIMIT написать так, чтоб он внутри не был full scan и затем sort, либо увы.

 ‎· яснополянская хлеборезка
Comment

или я слишком упрощаю? а что ещё важное?

 ‎· яснополянская хлеборезка
Comment

@qub: это заход с разных сторон. это конечно и про перформанс, но это не главное. Меня интересует, во-первых, то, что если тебе дают писать сырой SQL, то он может оказаться слишком мощный, надо бы сузить и не позволить выстрелить в ногу. Поэтому когда у тебя в птичьей записи оказывается слишком много определенных символов, то можно остановиться или подумать (ну или для быстрого хэширования — ты, условно, кидаешь своему DBA не простыню запроса, а краткую запись, и просишь вмешаться — и ему сильно быстрее понять, насколько всё плохо).

 ‎· псы в рапиде
Comment

Во-вторых, есть противоположное течение — из-за разных ORM'ок иногда люди хотят абстрагировать БД в такую тупую машинку, которая поддерживает WHERE/ORDER BY, а остальное часто "плохо помещается". Ну и соответственно, фичи платформы не используются (что в общем объяснимо), хотя часто БД-платформа у тебя на самом деле hardcoded, и в реальности переехать ты не сможешь.

 ‎· псы в рапиде
Comment

В-третьих, есть еще одно течение — максимально использовать БД и структуру таблиц так, чтобы их можно было оптимально использовать из приложения, а также проверять ошибки использования — это делается ЕЯПП через то, что называется SQL Catalog, и везде реализовано по-разному.

 ‎· псы в рапиде
Comment

^^^ ну DBA на план запроса смотреть ещё должен, может его лучше птичьим записывать?

 ‎· адский хардлайн в засаде
Comment

@larhat: ну мы предполагаем что эта коммуникация по какой-то причине происходит.

 ‎· псы в рапиде
Comment

@larhat: Кстати бл, это прекрасный вопрос, про визуализацию планов.

 ‎· псы в рапиде
Comment

^ pgadmin умеет так http://www.postgresonline.com/images/journal/explain_plan_8.png ; более текстовое есть такое — https://explain.depesz.com/s/Pti3

 ‎· адский хардлайн в засаде
Comment

@dma: бля, я наконец-то разобрался, чем CROSS JOIN отличается от FULL OUTER JOIN. ЖЭСТЬ.

 ‎· псы в рапиде
Comment

(В скобках замечу, что правильным языком для структуры запросов мне представляется теоретико-множественный, а для производительности — что-то вроде big-O notation. Буквальный перевод SQL, с его синтаксическим сахаром, кажется мне скорее тупиком.)

 ‎· 9000 3
Comment

(походил помедитировал между: [1] все это текст, и как же все же удивительно что его понимают и сука люди и бля компиляторы [2] IDEs показывают нам традиционные неинвазивные способы сделать корреспонденту понятнее -- отступы, синтаксическая раскраска, комментарии, схлопывалки-расхлопывалки и прочее подобное [3] что может быть итогом совместного чтения query? исправить query если она делает не то, переформулировать адскую хотя и правильную q, пилить индексы и прочие подобные внесиквельные вещи, менять таблички и структуру базы если проблема есть и иначе не решается [4] у DBA стопроц есть какой-нибудь там свой любимый data modeller или еще какая лопата [5] execution планов может быть много, они могут меняться в зависимости от данных, и вообще в том что они в большой степени независимы от query чуть ли не суть SQL [6] иначе все надо писать на явных курсорах и процедурах [7] какая же нотация может облегчить cognitive/mental workload анализа из п. 3, убыстрить или там квалификации меньше потребовать? [8] хз! ... [10] profit)

 ‎· яснополянская хлеборезка 5

1 2 3 4 5 6 7 8 9 10