Доступен выпуск языка формирования запросов и преобразования данных PRQL 0.9 (Pipelined Relational Query Language), развиваемого в качестве более простой и функциональной замены SQL, упрощающей создание сложных аналитических запросов. Код на языке PRQL компилируется в SQL, что позволяет использовать его с любыми реляционными СУБД. Компилятор PRQL написан на языке Rust и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59499
а если сразу на SQL писать?
Тогда PR не будет
Если если sql не больше нескольких строк то не проблема.У Sql есть недостаток. Он не модульный.
Нельзя сказать этот запрос такой же как этот только с небольшими изменения. У нас в проекте огромные запросы (по 3-4 страницы) а ещё код копипастится с десяток раз. Это очень плохо, код становится плохо поддерживаемым.
А ты не думал почему вы продолжаете делать именно так? Может потому что по другому просто не может работать?
views не помогает? Или динамический sql?
Да, динамический sql подходит. Но если генерируется то что должно создаваться руками - это признак что язык который генерируется - плохой.
Код писать нормально просто надо. Это у вас проблемы, а не у SQL
про хранимки не слышал?
Реляционные базы и так плохо маштабируются. Как будет производительность с хранимкам не знаю, но да, там с повторным использованием кода получше
> Как будет производительность с хранимкам не знаюТебе никто не мешает сделать хранимку с обычным SQL-ом.
>Тебе никто не мешает сделать
>хранимку с обычным SQL-ом.Тогда непонятно для чего хранимка
Категорически не советую никакие "хранимки" - мало того, что это в принципе уё6ство - писать на кривом недоязыке "процедуры" (привет новичкам проекта!), так ещё они не переносимы. Идеальная схема: СУБД исключительно для данных, вся логика на апп-сервере. В случае чего - можно СУБД даже полностью сменить, не говоря о простоте портирования на более свежие версии.
>Идеальная схемаОтнюдь не идеальная. Как вы целостность данных собираетесь обеспечивать, если кто-то решит мимо сервера приложений нагадить?
Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?
>В случае чего - можно СУБД даже полностью сменить
Чего, например?
>не говоря о простоте портирования на более свежие версии
Какие там сложности?
Если кто-то может мимо сервера приложений "гадить", найдется и DBA, который это дело поправит.
Но к тому времени уже может оказаться поздно что-либо поправлять.
> если кто-то решит мимо сервера приложений нагадить?Давай такие ТУХЛЫЕ аргументы не приводить? А то я скажу, что у тебя нет защиты от "уборщица пришла с пылесосом и выдернула розетку сервера". Ты как-то мыслишь вообще не по-программистски.
> Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?
А в чём именно проблема-то?? Подробнее.
> Чего, например?
Чего "чего"? ДВИЖОК сменить! Что непонятного?
> Какие там сложности?
Все те же сложности, как и перенос чего-либо вообще на другой физический сервер - то с форматом дат напутали, то нашлись неконсистентные данные, то надо перенести блобы из файловой системы в новое место (а в старой базе пути). Я не просто про "бэкап-рестор", а аккуратный перенос данных, потому что незачем тащить на новый сервер все старые атавизмы. И конечно процедуры - обратная совместимость у них есть, но как всегда найдётся энтузазист, который захочет переписать короче (а ради чего тогда прогресс??). И вот уже у вас ДВЕ версии хранимок.
Я не понимаю, зачем вообще что-либо писать на сервере, используя неуклюжий T/SQL или PL/SQL. Есть родной ЯП, пусть даже это и пестон какой-нть, какой смысл ОТДЕЛЬНО писать на ещё одном языке??
Такая схема подходит для небольших, средних проектов. Они могут себе позволить "эксперименты" с "а давай сегодня сменим СУБД на ту, а через месяц на вон ту...".
> В случае чего - можно СУБД даже полностью сменитьПостоянно слышу этот аргумент, а в реальности как часто проекты меняют СУБД?
Вот прям сейчас идёт масштабный эксперимент по смене Oracle на PostgreSQL.
Даже при том, что внутренний язык подогнали, всё идёт как-то не очень.
Потому что нельзя за год "подогнать" то, что создавалось десятки лет. Могли бы сменить парадигму, раз уж такое дело, но нет - хотят бесплатный оракл, альтернативные подходы не хотят.
Речь не про "бесплатный Oracle", а про импортозамещение в связи с тем что Oracle теперь в РФ не продаётся.
> Категорически не советую никакие "хранимки"Человеку надо переиспользовать SQL. Хранимки для этого вполне подходят. Можно ещё и CTE использовать, но оно без параметров.
> в принципе уё6ство - писать на кривом недоязыке
Язык SQL.
Есть разница между бизнес-логикой и логикой целостности данных. Не всё можно уложить в constraints.Типичный случай - умышленная денормализация в целях повышения производительности, например, всякие счётчики.
В Постгресе в большинстве случаев можно обойтись CREATE RULE, описывая событие и реакцию на него на чистом SQL. Это, конечно, не портабельно, но и триггеры-хранимки тоже не портабельны, зато не возникает соблазна засунуть туда ващевсё
> Реляционные базы и так плохо масштабируются.Зависит от архитектуры приложения вобще-то. Например, отдельные модули в отдельной схеме (базе данных) без сильных связей с другими схемами (базами данных) вполне себе отлично разносятся по разным хостам. Есть и другие способы разнесения нагрузки, типа репликации мастер-мастер, мастер-ведомый, и так далее.
Да, это не "СУБД" типа "ключ-значение", но зато РСУБД и гораздо больше чего умеет из коробки.
А так серебряной пули не бывает.
так прекратите писать sql-спагетти, и разгребите ваши запросы.
у вас видимо текучка кадров большая :)
Чта?!Во первых в sql есть view.
Во вторых with.Что покрывает все потребности в модульности.
VIEW, CTE и функции, включая табличные, решают проблему лишь частично.
Мне радикально решить проблему модульности удалось лишь препроцессингом SQL кода средствами C препроцессора. Вот когда появились включаемые файлы и макросы - тогда действительно код стал модульным.
К сожалению, инлайн код в запросе намного производительней, чем тот же код, вынесенный в функции. А у меня даже такие запросики возникают: https://github.com/dbeaver/dbeaver/issues/10680 (смотрите аттач в zip). При том, что до препроцессора, это вполне себе компактный запрос:SELECT ROUND(Q.Rez-UC_DISCOUNT,0)+CALC_JA_TOTAL
FROM ...
Модулей в SQL быть не может, однако от дублирования избавиться можно.
1) Можно повторяющийся SQL инклюдить из файла.
2) Можно написать класс билдера запросов для моделей, одноклассники которого смогут экспортировать миксины для построения запроса, а также использовать их для построения своих запросов. Очень грубо, можно передать список вещей, которые нужно добавить в те или иные части запроса, и что нужно потом сделать с результатом запроса. Например, можно добавить в группировку и в селект, а после исполнения развернуть group_concat в массивчик айдишек и т.д. В одном из проектов я такую вещь сделал и несмотря на некую навороченность кода, SQL существовал в единственном экземпляре. Запросы на экран и более были нормой, да.
> Модулей в SQL быть не можетЯ бы не был столь категоричным. View - вполне себе самостоятельный модуль. Есть и ещё, попроще, не так, чтобы модули, но вполне нормальный способ сократить дублирование кода. В Oracle использование функций в теле SQL-запроса подвезли с 19-й версии. Кроме того, есть with, как уже отметили выше.
Фактически это макросы. Подсократить запросы получится, спору нет.
Проблему решает просто препроцессинг SQL кода, например, C препроцессором. Сразу же SQL модульный становится, благодаря макросам и включаемым файлам.
Это изврат ради изврата. Сиквелу совершенно ни к чему быть модульным.
Тогда навеки один sql и отсанется. Тут же есть шанс дать аналитику UML- инструмент, а когда понадобиться скомпилировать, к примеру, в код для Pandas, своей биг даты и т.п.
Для Pandas, если не ошибаюсь, есть отдельный модуль, который позволяет обращаться к библиотеке в виде диалекта SQL. А всё почему? А всё потому, что родной API библиотеки Pandas для конструирования сколь-либо сложных запросов - редкое г..ще.
Пиши. Сразу на несколько диалектов. И переписывай. И поддерживай. Никаких проблем. Ещё хранимками обмазаться для полноты ошушений.
вася - лечись давай.
--
на ккой ляд на несколько диалектов писать?
2 субд понянешь за раз?)
Писать на SQL и компилировать в PRQL. И технологию поиспользовали и волки довольны. Да по сути он ничем не отличается, просто порядок поменяли и функции поменяли на нечитаемые символы. В чём удобство? В том что нужно учить новый язык, которые затухнет через полгода?
Посредники всегда источник проблем. Кроме того, тут точно будет куча багов из-за ржавчины. Я раньше нейтрально относился к ней, но это удивительно гнилая экосистема с низкоквалифицированным комьюнити разработчиков.
Так и сабж низкоквалифицированный. Для бенчмарков, которые они будут показывать тем кто ничего не понимает.
То какую-то императивщину вместо регулярок, то SQL лишь бы не писать... Эпоха ORM все? Оказались слишком сложны/тупы и нужен все-таки язык запросов? Теперь начинаем языки запросов лепить?
>как в PythonКто занимается подобной ерундой? Ну конечно же они - питонисты.
>ORMэто вообще хлам. Годится для тупого хранения данных и доступа к ним по ключу только. Движок и оптимизатор запроса в базе данных они не задействуют.
Дружище, оптимизатор запросов задействует сама СУБД. Ей навалить как был запрос сформирован - руками написан или сгенерирован ORMкой. Для СУБД нет разницы. Так что странное высказывание.
Нормальные orm поверх sql баз данных предоставляют очень многого всего чего иначе пришлось бы писать самому. Миграции, транзакции, сериализация данных на структуры в ЯП, логгер, даже всякие плагины к ORM, очередь на запись чтение даже внутри простого приложения. Другое дело что нормальных ORM реально практически не существует, я перепробовал почти все как для Go так и для Python, у всех адская боль и безобразие при работе с Many To Many relations. Many To Many можно реализовать практически каждым из типов JOIN но каждая ORM делает по своему. Есть такая проприетарная вендовая тулза Data Extractor v3 так вот она может оптимизировать SQL запросы сгенерированные каждым из ORM, то есть там с эффективностью тоже проблемы. Все из-за того что синтаксис SQL это устаревший шлак времен ледникового периода.
> нормальных ORM реально практически не существуетЭто правда.
> синтаксис SQL это устаревший шлак времен ледникового периода
А это - нет. В чём конкретно его недостатки? В том, что ORM фигню генерирует? Но причём тут SQL?
https://docs.sqlalchemy.org/en/20/orm/basic_relationships.ht...Чего не хватает?
ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истиныэто как со сломанными часами, которые показывают правильное время 2 раза в сутки
> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истиныЕсть, конечно. ORM с точки зрения конечной производительности системы - это часто хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы, чем вот эти поделия.
>> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
> Есть, конечно. ORM с точки зрения конечной производительности системы - это часто
> хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы,
> чем вот эти поделия.брехня, "квалифицированный программист" не использует плохие орм, а те, которые пригодны точно знает как надо использовать, чтобы код получался такой же как и при ручном его написании
Нет, проблема ORM-ов не в адекватности запросов -- в сиквеле пофиг как ты написал, гадалка всё равно сделает так, как нужно, главное, чтоб логически было верное выражение, а у ОРМов с этим более-менее. У ORM-ов просто много накладных расходов. А сейчас ещё и добавляет то, что вошли в моду ормы поверх ормов и поверх ормов. В той же java сейчас модно лепить всякую жуть над jpa.
хорошо хоть АКТИВ РЕКОРД не вспомнил
А что с ним не так? Можно развернуто?
Если вся логика - это тупой crud, то ничего плохого в нем нет. А вот когда сложную бизнес-логику пытаются запихать в AR, начинается полная жесть.https://www.mehdi-khalili.com/orm-anti-patterns-part-1-activ...
"active record gone crazy"
Другое дело, что 9 из 10 проектов - аккурат круд и есть
может эксперт и не вкурсе, но АКТИВ РЕКОРД это собссно один из способов реализации ORM. подсказка: второй - это ДАТА МАППЕР.
а Linq provider это куда? )))
LINQ это язык запросов. ORM на которую мапятся LINQ запросы это Entity Framework. Entity Framework это паттерн Data mapper, не active record.
А как он будет оптимизировать запрос под конкретные базы? И не только запрос, но и схему самих баз. Мне однажды пришлось паковать два поля в целое число - rowid для SQLite. По другому было бы жутко медленно. А так был жутко медленный импорт, а остальные релевантные запросы - быстры.
Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
боюсь, что начинающий тут ты. оно предлагает написать руками по сути query execution plan.
из минусов, только 2 конверсии внутри в скл, и в план обратно.
> боюсь, что начинающий тут ты. оно предлагает написать руками по сути query
> execution plan.
> из минусов, только 2 конверсии внутри в скл, и в план обратно.Да? И какой сервер его будет выполнять?
а там вариантов много... пг, мускл, мс скл и проч
прям "в ассортименте"
> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".но и ты ее не осилил
>> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
> но и ты ее не осилилЕстественно, я ж тебе не начинающий!
> Обвязки для использования PRQL развиваются для языков Java, JavaScript, .NET, Elixir, R, Rust, PHP и PythonЯ негодую! Где поддержка Go ?!
Там прослойка элементарная - преобразование строк и прокидывание опций транслятору, даже раст не особо нужно знать.
Прояви себя вместо негодования - набросай свою интеграцию.
О чем ты? Какая поддержка? Го для хиптанов. А PRQL для нормальных людей. Они с хиптанами не связываются.
> Rust
Каким образом это проще SQL?Сложность SQL в понимании реляционной алгебры, а это никакими изменениями синтаксиса не решить: тут либо понял, либо нет.
А читается эта фигня точно сложнее, чем SQL.
Проще чем кажется, на самом деле.
> читается эта фигня точно сложнее, чем SQLБолее ущербного синтаксиса, чем у sql, представить сложно. А сабж читается легко, на уровне привычного разрабам array.filter(...).groupBy(...).filter(...).sort(...).
Ирония в том, что sql начинался как язык для непрограммистов. Типа бухгалтеры будут напрямую вбивать запросы на английском языке. Оказалось, что язык, изначально рассчитанный для программистов, читается легче, чем тот, что рассчитывался для непрограммистов. Сравни синтаксис си и бейсика например. В си все предсказуемо, а в бейсике каждая новая функция -- это каждый раз новый синтаксис.
Ирония в том что ты считаешь что твоя лапша удобнее sql.
> лапшалапша — это WITH table_1 AS ( SELECT customer_id, total - 0.8 AS _expr_0, invoice_date FROM invoices ), table_0 AS ( SELECT COALESCE(SUM(_expr_0), 0) AS sum_income, COUNT(*) AS ct, customer_id FROM table_1 WHERE _expr_0 > 5 AND invoice_date >= DATE '2010-01-16' GROUP BY customer_id ) SELECT c.customer_id, CONCAT(c.last_name, ', ', c.first_name) AS name, table_0.sum_income, table_0.ct, version() AS db_version FROM table_0 JOIN customers AS c ON table_0.customer_id = c.customer_id ORDER BY table_0.sum_income DESC LIMIT 10
Форматирование спасёт отца русской демократии!
Объсни что не так? Если ты не умеешь форматирование это не значит что все не умеют в форматирование.
Отформатировать и будет все понятно. Да, запрос очень простой. Когда попишешь запросы сложные, расхочется заменять на императивщину.
навалил в одну строку черти что - чертичто и называется лапшой, а не SQL. ты путаешься.
для программистов есть query builder-ы на том языке, на котором само приложение.Тот же SQLAlchemy ничем не хуже (и даже лучше) описанного, при этом нет никакого разделения на разные языки.
тут как раз один язык запросов и биндинги под разные языки и бд
Это плохо.
А зачем?
Сколько раз в жизни приходилось переносить код query builder-а с одного языка программирования на другой? Большинству 0, кому-то, может, 1 раз за 10 лет.
При этом query builder на том же языке, что и всё приложение, имеет очевидные преимущества как по интеграции с остальным кодом, так и по использованию инструментария.
В чем сложность понимания реляционной алгебры? Это что за такие сложности?
ну если таблиц пара - легко. а если 25 (д, агалитика, та самая), то схему данных удерживать в голове... на 24 шага слияния... сложно.
но может есть гении..
show tables;87 rows in set (0.000 sec)
explain запроса сделай и посмотри, сколько там в плане шагов. 87 таблиц может быть из-за того, что 5 сервисов в одну базу сpут. Половина таблиц справочники. Знаем мы вас. Сколько из этих табличек содержат более 100000 строк?
У тебя есть запросики, где ты одну и ту же табличку джойнишь чуть-чуть по-разному 3-5 раз? Колбасы из 10-20 лефт джойнов, зависящие друг от друга и от 5 иннер джойнов выше? Запросы более чем в пару экранов в высоту? Случалось ли придумывать логику запроса больше трех дней, а не за чашечкой кофе?
> У тебя есть запросики, где ты одну и ту же табличку джойнишь чуть-чуть по-разному 3-5 раз? Колбасы из 10-20 лефт джойнов, зависящие друг от друга и от 5 иннер джойнов выше?
> Случалось ли придумывать логику запроса больше трех дней, а не за чашечкой кофе?я же не долбаеб делать такую убогую структуру базу данных, чтобы потом костылить это запросами
сложные запросы конечно есть, но то, что ты написал это не маст-хэв
> Половина таблиц справочники.
конкретно в этой БД, справочников нет вообще
> Знаем мы вас.
ты и себя то с трудом )))
> Сколько из этих табличек содержат более 100000 строк?
если речь о "схему данных удерживать в голове" то какая разница, это таблица на 100 тыс, 5 тыс, или вообще очищаемая очередь?
> 87 таблиц может быть из-за того, что 5 сервисов в одну базу сpут.
это одно веб приложение, параллельно с ним в базу обращаются только сервисы например занимающиеся почтовой рассылкой, но ВНЕЗАПНО )) обращающиеся к тем же таблицам, даже если предположить, что их 5 (почта + еще 4 каких-то), то для контроля состояния фонофых задач, на каждый тип задачи не потребуется больше одной таблицы, т.е. условно 82 вместо 87
так что ты там знаешь? ))))
Короче наплодили сущностей, данных у вас толком нет, запросы простые. Понтов много :)
У меня стабильно проекты, где больше 100 только основных сущностей, а всякие связи вообще никто не считает.
>это не маст-хэвНачальству как будешь объяснять, что им на самом деле не нужны эти данные/отчеты/аналитика?
>какая разница, это таблица на 100 тыс, 5 тыс, или вообще очищаемая очередь?С таблицами на 5 тысяч можно писать в принципе любые запросы и ничего тормозить не будет, с 100т уже требуется думать головой, а когда часть таблиц имеет миллионы и десятки миллионов строк, уже приходится как-то изворачиваться.
Понятно, если ты г-кодишь новые проекты, ты никогда не увидишь ничего подобного. Пустые таблицы, не усложненная нюансами практики бизнес-логика, аналитики нет или она в зачатке.
смешались у тебя кони люди в одном сообщении ))) с логикой у тебя бедав этой бд есть таблицы на десятки миллионов строк, но какое отношение это имеет к "удержанию в голове СХЕМЫ"?
Когда у тебя большие таблицы, помимо схемы тебе надо думать еще и о количестве данных. Не сталкивался с таким? Ну да, это не маст-хэв, ведь у тебя работу принимают с пустыми базами.
почитай оригинальный коментарий, и что именно обсуждаетсянет никакой сложности держать схему базы данных больше 24 таблиц в голове (количества строк это вообще не касается), может поэтому тебе и тяжело держать все голове потому что там постоянная каша из котлет и мух?
> почитай оригинальный коментарий, и что именно обсуждается
> нет никакой сложности держать схему базы данных больше 24 таблиц в голове
> (количества строк это вообще не касается), может поэтому тебе и тяжело
> держать все голове потому что там постоянная каша из котлет и
> мух?человек пытается сказать, что чем объемнее таблицы, тем аккуратнее надо быть при написании запросов. и тем сложнее держать в умер все ньюансы. если у тебя 25 таблиц - это круто. я видел например базы данных MS Dynamics, в которой если не изменяет память их было больше 4х тысяч. да, бизнес сущностей.
тут проблема в чем - подход который у тебя - бессмысленнаю трата ресурсов мозга. а тот подход, который предлаете интрумент описаный в статье - он позволяет оперировать информацией с меньшими ментальными издержками.
уже все давно придумано, называется CASE Tools, в частности для Data Modelingи неважно сколько строк в таблицах, запрос к правильно спроектированной БД, будет оптимальным чаще всего только одним единственным способом (если не считать Views), вот его и пишешь независимо от того сколько строк
а подход "там будет строк немного, поэтому тут мы можем недопроектировать или на отъeбись сделать" это не ко мне с такими дискуссиями )))
Да меня это тоже удивляет, но 90% кандидатов на собеседованиях валятся на простейших вопросах на join-ы.
а где биндинги для с++ и с????????????????
Тут https://github.com/PRQL/prql/tree/main/bindings/prql-lib
лол, будто ты что-то пишешь на них
О ! Они переизобрели Natural !!! Был такой язык для СУБД ADABAS в 80х.
50 лет и круг замкнулся.Ещё немного подождать и появится новый SQL "на стероидах"
У меня устойчивое дежа-вю, что лет 10 назад уже было нечто похожее.
Про любой язык так можно сказать. Ничего они не переизобретали.
Сейчас бы делать абстракцию над абстракцией.
И с SQL то не всегда непонятно как будет база запрос обрабатывать, а с этой штукой и по давно.
Ну от растоманов ничего другого и не ждал.
В чем тут непонятность? И в чем не понятность как база будет запрос обрабатывать? Обрадую вас: повсюду тонна инструмнетов для анализа - и это уже давно решенная проблема (обрадую вас №2).
Может быть просто надо вылезти из 2002 года и начать уже опльзоваться современными инструментами?
Как будет выполняться запрос никак с SQL вообще не связано.
Да ... вдогонку к 1.22 - это будет новый микросервисный, объекто-ориентированный, с параллельной обработкой, SQL !!!
как будто это что-то плохое
Ты, наверное, любитель стимпанка.
Хороший язык. На нём можно даже ОС написать.
Почему никто не написал?
говорят, написали
PL/pgSQL - меня вполне устраивает, а мускулём или машей не пользуюсь в сложных проектах, но проект выглядит интересным, нужно будет потыкать палочкой.
Процедурки над сиквелом, кроме Оракла, везде плохо. В Слоне тоже. Использовать можно только строго для реализации констраинтов или простейших триггеров.
переизобрели 1с?
--
для разового запроса, оно, возможно, подойдёт. но если юзер идийот - то сервер ляжет нахер...
--
а вообще - нехер каждой амёбе давать доступ к базе. знание sql - как тест на профпригодность: можно к отдельным строкам r\o давать и организовать несколько шаблонов запросов)
угу, а потом отгребать нетестируемые баги из-за смеси непонятно каких подзапросов, и sql injection, потому, что подставили, ой, нитуда и нито, и ниправерили.
Да какой 1С, он вообще на всяких кассиров пятьорочки рассчитан и хотя бы концептуально (ЯП для непрограммистов) смысл имеет. А это - попытка впихнуть ещё один слой абстракции над и так очень абстрактной шелухой, типичный пример поделия от последователей карго-культа.
PR QL - в названии вся суть.
Такое ощущение, что ребятам от моднявок даже в SQL сложно.
уточняйте сразу что поделка на расте, чтобы время наше не тратить. Посмотрел cargo.lock и понял что надо выбрасывать: https://github.com/PRQL/prql/blob/main/Cargo.lock
SQL - декларативный, PROL - не декларативный, не процедурный и не объектный.
А программисты любят ORM - из объектов ходят в SQL. Это как раз понять можно, автоматические методы CRUD многим нравятся.Хотя даже такое нужно с осторожность использовать.Проблемы с производительностью таки бывают. ORM API есть для C++,Java,Python.
Для чего здесь не объектный PROL и где его место?
Аналитические запросы - это когда запрашивают отдельные огромные столбцы и сразу с аггрегацией. Это не про релационные базы данных, где всё строками. А какая вообще аналитическая БД использует SQL?
Apache Phoenix
ClickHouse
например Vertica
А уже есть такой язык, наз-ся "dplyr" / "dbplyr" из R. Точно также может транслироваться в различные диалекты SQL или вообще просто выполняться локально. Пример переводится буквально построчно:employees |>
filter(start_date > as_date('2021-01-01')) |>
mutate(
gross_salary = salary + tax,
gross_cost = gross_salaray + benefits_cost
) |>
filter(gross_cost > 0) |>
group_by(title, country) |>
summarise(
gross_summary = mean(gross_salary),
sum_gross_cost = sum(gross_cost)
) |>
ungroup() |>
filter(sum_gross_cost > 1e5) |>
mutate(
id = glue_data('{title}_{country}'),
coutry_code = str_sub(country, 1, 2)
) |>
arrange(sum_gross_cost, -country) |>
slice_head(n = 20)
Выглядит прилично, посмотрим, что из этого выйдет
Не взлетит. Можете скринитьЯ подобную поделку лет 15 назад делал, потом понял что это нафиг никому не нужный мусор
А в классических книжках был QUEL. И тоже его что-то никто не юзает
Они сделали версию Mule DataWave? У мула эта штука очень удобная, но применимая к абсолютно любому потоку данных например из сети.
Я только не понял:
- как тут с оконными функциями жить, вроде LAG, LEAD и т.п.?
- как сюда GROUPING SETS прикрутить?
- как APPLY/LATERAL описать?
- как с интервалами, диапазонами и массивами этим работать?
- как динамический SQL этим формировать?Короче, больше вопросов, чем ответов. Этой шняге еще годы и годы расти до возможности практического применения.
Можно, конечно, добавить его, как еще один процедурный язык в PostgreSQL. Но толку?