The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опубликован PRQL, компилируемый в SQL язык обработки данных

26.07.2023 15:29

Доступен выпуск языка формирования запросов и преобразования данных PRQL 0.9 (Pipelined Relational Query Language), развиваемого в качестве более простой и функциональной замены SQL, упрощающей создание сложных аналитических запросов. Код на языке PRQL компилируется в SQL, что позволяет использовать его с любыми реляционными СУБД. Компилятор PRQL написан на языке Rust и распространяется под лицензией Apache 2.0.

PRQL позволяет формировать сценарии обработки данных в форме конвейеров, в которых по цепочке друг за другом выполняются операции преобразования, которые могут включать блоки для фильтрации потока данных, выполнения вычислении и таких действий, как сортировка, агрегирование и группировка. Поддерживается разделение проекта на несколько файлов. В сценариях PRQL допускается определение функций, использование циклов, создание переменных, массивов, регулярных выражений и кортежей. При необходимости поддерживается прямая подстановка SQL-кода в сценарии на PRQL.

В разработке находится возможность использования системы типов и модулей. В планах упоминается расширение библиотеки функций и предоставление плагинов для интеграции с интегрированными средами разработки. В отдалённой перспективе намечено создание компилятора из SQL в PRQL и разработка бэкендов для других языков запросов, таких как RQ (Relational Query).

Обвязки для использования PRQL развиваются для языков Java, JavaScript, .NET, Elixir, R, Rust, PHP и Python. Через плагины обеспечена интеграция с Jupyter/IPython, Visual Studio Code и Prefect. Подготовлено расширение для выполнения кода PRQL в СУБД DuckDB. В компиляторе поддерживается генерация SQL с учётом диалектов и возможностей, применяемых в СУБД PostgreSQL, MySQL, DuckDB, Сlickhouse, MS SQL и SQLite. Для тестирования компиляции предложен online-сервис, работающий в браузере.

Пример кода:


   from employees
   filter start_date > @2021-01-01      # более понятный синтаксис работы с датами
   derive {                             # блок derive для добавления столбцов и переменных
     gross_salary = salary + (tax ?? 0),         
     gross_cost = gross_salary + benefits_cost,  
   }
   filter gross_cost > 0
   group {title, country} (             # блок group выполняет код для каждой группы
     aggregate {                        # блок aggregate агрегирует группу в значение    
       average gross_salary,
       sum_gross_cost = sum gross_cost, 
     }
   )
   filter sum_gross_cost > 100_000      # блок filter заменяет SQL-операции WHERE и HAVING.

   derive id = f"{title}_{country}"     # f-строки, как в Python
   derive country_code = s"LEFT(country, 2)"  # s-строки для прямой вставки SQL-кода
   sort {sum_gross_cost, -country}            # минус сигнализирует сортировку в обратном порядке
   take 1..20                           # take задаёт диапазон для вывода


  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Опубликован стандарт SQL:2023
  3. OpenNews: Опубликован DuckDB 0.6.0, вариант SQLite для аналитических запросов
  4. OpenNews: Релиз языка для формирования структурированных запросов HTSQL 2.0
  5. OpenNews: Facebook представил новый язык формирования запросов GraphQL
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59499-prql
Ключевые слова: prql, sql, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (125) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 16:25, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    а если сразу на SQL писать?
     
     
  • 2.2, Perlovka (ok), 16:26, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +22 +/
    Тогда PR не будет
     
  • 2.27, Дмитрий (??), 17:32, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если если sql не больше нескольких строк то не проблема.

    У Sql есть недостаток. Он не модульный.
    Нельзя сказать этот запрос такой же как этот только с небольшими изменения. У нас в проекте огромные запросы (по 3-4 страницы) а ещё код копипастится с десяток раз. Это очень плохо, код становится плохо поддерживаемым.

     
     
  • 3.28, Аноним (28), 17:38, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    А ты не думал почему вы продолжаете делать именно так? Может потому что по другому просто не может работать?
     
  • 3.31, Твайлайт Спаркл (ok), 17:59, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    views не помогает? Или динамический sql?
     
     
  • 4.53, Дмитрий (??), 19:39, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, динамический sql подходит. Но если генерируется то что должно создаваться руками - это признак что язык который генерируется - плохой.
     
  • 3.38, Аноним (38), 18:41, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Код писать нормально просто надо. Это у вас проблемы, а не у SQL
     
  • 3.52, Rodegast (ok), 19:22, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    про хранимки не слышал?
     
     
  • 4.57, Дмитрий (??), 19:47, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Реляционные базы и так плохо маштабируются. Как будет производительность с хранимкам не знаю, но да, там с повторным использованием кода получше
     
     
  • 5.63, Rodegast (ok), 20:18, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Как будет производительность с хранимкам не знаю

    Тебе никто не мешает сделать хранимку с обычным SQL-ом.

     
     
  • 6.130, Дмитрий (??), 00:43, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Тебе никто не мешает сделать
    >хранимку с обычным SQL-ом.

    Тогда непонятно для чего хранимка

     
  • 5.85, Аноним (85), 01:57, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Категорически не советую никакие "хранимки" - мало того, что это в принципе уё6ство - писать на кривом недоязыке "процедуры" (привет новичкам проекта!), так ещё они не переносимы. Идеальная схема: СУБД исключительно для данных, вся логика на апп-сервере. В случае чего - можно СУБД даже полностью сменить, не говоря о простоте портирования на более свежие версии.
     
     
  • 6.86, Прохожий (??), 03:07, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Идеальная схема

    Отнюдь не идеальная. Как вы целостность данных собираетесь обеспечивать, если кто-то решит мимо сервера приложений нагадить?

    Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?

    >В случае чего - можно СУБД даже полностью сменить

    Чего, например?

    >не говоря о простоте портирования на более свежие версии

    Какие там сложности?

     
     
  • 7.117, Аноним (117), 16:56, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если кто-то может мимо сервера приложений "гадить", найдется и DBA, который это дело поправит.
     
     
  • 8.121, Прохожий (??), 20:21, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но к тому времени уже может оказаться поздно что-либо поправлять ... текст свёрнут, показать
     
  • 7.151, Аноним (151), 06:02, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Давай такие ТУХЛЫЕ аргументы не приводить А то я скажу, что у тебя нет защиты о... большой текст свёрнут, показать
     
  • 6.88, Аноним (88), 04:21, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Такая схема подходит для небольших, средних проектов. Они могут себе позволить "эксперименты" с "а давай сегодня сменим СУБД на ту, а через месяц на вон ту...".
     
  • 6.89, ойвэй (?), 04:38, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В случае чего - можно СУБД даже полностью сменить

    Постоянно слышу этот аргумент, а в реальности как часто проекты меняют СУБД?

     
     
  • 7.101, 1 (??), 09:08, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот прям сейчас идёт масштабный эксперимент по смене Oracle на PostgreSQL.
    Даже при том, что внутренний язык подогнали, всё идёт как-то не очень.
     
     
  • 8.118, Аноним (117), 16:58, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что нельзя за год подогнать то, что создавалось десятки лет Могли бы с... текст свёрнут, показать
     
     
  • 9.145, Нанонимус53 (?), 01:01, 02/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Речь не про бесплатный Oracle , а про импортозамещение в связи с тем что Oracle... текст свёрнут, показать
     
  • 6.114, Rodegast (ok), 15:02, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Категорически не советую никакие "хранимки"

    Человеку надо переиспользовать SQL. Хранимки для этого вполне подходят. Можно ещё и CTE использовать, но оно без параметров.

    > в принципе уё6ство - писать на кривом недоязыке

    Язык SQL.

     
  • 6.137, Аноним (137), 19:13, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Есть разница между бизнес-логикой и логикой целостности данных. Не всё можно уложить в constraints.

    Типичный случай - умышленная денормализация в целях повышения производительности, например, всякие счётчики.

    В Постгресе в большинстве случаев можно обойтись CREATE RULE, описывая событие и реакцию на него на чистом SQL. Это, конечно, не портабельно, но и триггеры-хранимки тоже не портабельны, зато не возникает соблазна засунуть туда ващевсё

     
  • 5.122, Прохожий (??), 20:31, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Реляционные базы и так плохо масштабируются.

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

    Да, это не "СУБД" типа "ключ-значение", но зато РСУБД и гораздо больше чего умеет из коробки.

    А так серебряной пули не бывает.

     
  • 3.91, Аноним (91), 05:50, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так прекратите писать sql-спагетти, и разгребите ваши запросы.
    у вас видимо текучка кадров большая  :)
     
  • 3.94, Аноним (94), 06:56, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Чта?!

    Во первых в sql есть view.
    Во вторых with.

    Что покрывает все потребности в модульности.

     
     
  • 4.134, ptr (??), 08:47, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    VIEW, CTE и функции, включая табличные, решают проблему лишь частично.
    Мне радикально решить проблему модульности удалось лишь препроцессингом SQL кода средствами C препроцессора. Вот когда появились включаемые файлы и макросы - тогда действительно код стал модульным.
    К сожалению, инлайн код в запросе намного производительней, чем тот же код, вынесенный в функции. А у меня даже такие запросики возникают: https://github.com/dbeaver/dbeaver/issues/10680 (смотрите аттач в zip). При том, что до препроцессора, это вполне себе компактный запрос:

    SELECT ROUND(Q.Rez-UC_DISCOUNT,0)+CALC_JA_TOTAL
    FROM ...

     
  • 3.119, Аноним (117), 17:24, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Модулей в SQL быть не может, однако от дублирования избавиться можно.
    1) Можно повторяющийся SQL инклюдить из файла.
    2) Можно написать класс билдера запросов для моделей, одноклассники которого смогут экспортировать миксины для построения запроса, а также использовать их для построения своих запросов. Очень грубо, можно передать список вещей, которые нужно добавить в те или иные части запроса, и что нужно потом сделать с результатом запроса. Например, можно добавить в группировку и в селект, а после исполнения развернуть group_concat в массивчик айдишек и т.д. В одном из проектов я такую вещь сделал и несмотря на некую навороченность кода, SQL существовал в единственном экземпляре. Запросы на экран и более были нормой, да.
     
     
  • 4.123, Прохожий (??), 20:41, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Модулей в SQL быть не может

    Я бы не был столь категоричным. View - вполне себе самостоятельный модуль. Есть и ещё, попроще, не так, чтобы модули, но вполне нормальный способ сократить дублирование кода. В Oracle использование функций в теле SQL-запроса подвезли с 19-й версии. Кроме того, есть with, как уже отметили выше.

     
     
  • 5.136, Аноним (117), 15:35, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Фактически это макросы. Подсократить запросы получится, спору нет.
     
  • 3.131, ptr (??), 07:15, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проблему решает просто препроцессинг SQL кода, например, C препроцессором. Сразу же SQL модульный становится, благодаря макросам и включаемым файлам.
     
     
  • 4.146, Аноним (146), 15:15, 02/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это изврат ради изврата. Сиквелу совершенно ни к чему быть модульным.
     
  • 2.32, Аноним (32), 18:03, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Тогда навеки один sql и отсанется. Тут же есть шанс дать аналитику UML- инструмент, а когда понадобиться скомпилировать, к примеру, в код для Pandas, своей биг даты и т.п.
     
     
  • 3.124, Прохожий (??), 20:46, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Для Pandas, если не ошибаюсь, есть отдельный модуль, который позволяет обращаться к библиотеке в виде диалекта SQL. А всё почему? А всё потому, что родной API библиотеки Pandas для конструирования сколь-либо сложных запросов - редкое г..ще.
     
  • 2.37, Карлос Сношайтилис (ok), 18:40, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Пиши. Сразу на несколько диалектов. И переписывай. И поддерживай. Никаких проблем. Ещё хранимками обмазаться для полноты ошушений.
     
     
  • 3.60, Bob (??), 20:06, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вася - лечись давай.
    --
    на ккой ляд на несколько диалектов писать?
    2 субд понянешь за раз?)
     
  • 2.127, fuggy (ok), 21:15, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Писать на SQL и компилировать в PRQL. И технологию поиспользовали и волки довольны. Да по сути он ничем не отличается, просто порядок поменяли и функции поменяли на нечитаемые символы. В чём удобство? В том что нужно учить новый язык, которые затухнет через полгода?
     

     ....большая нить свёрнута, показать (36)

  • 1.3, Аноним (3), 16:28, 26/07/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –3 +/
     

  • 1.4, Аноним (4), 16:32, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    То какую-то императивщину вместо регулярок, то SQL лишь бы не писать... Эпоха ORM все? Оказались слишком сложны/тупы и нужен все-таки язык запросов? Теперь начинаем языки запросов лепить?
    >как в Python

    Кто занимается подобной ерундой? Ну конечно же они - питонисты.

     
     
  • 2.7, Аноним (7), 16:37, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >ORM

    это вообще хлам. Годится для тупого хранения данных и доступа к ним по ключу только. Движок и оптимизатор запроса в базе данных они не задействуют.

     
     
  • 3.87, Ruslan (??), 03:42, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дружище, оптимизатор запросов задействует сама СУБД. Ей навалить как был запрос сформирован - руками написан или сгенерирован ORMкой. Для СУБД нет разницы. Так что странное высказывание.
     
  • 3.90, cheburnator9000 (ok), 05:28, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальные orm поверх sql баз данных предоставляют очень многого всего чего инач... большой текст свёрнут, показать
     
     
  • 4.125, Прохожий (??), 20:51, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > нормальных ORM реально практически не существует

    Это правда.

    > синтаксис SQL это устаревший шлак времен ледникового периода

    А это - нет. В чём конкретно его недостатки? В том, что ORM фигню генерирует? Но причём тут SQL?

     
  • 4.138, Аноним (137), 19:17, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://docs.sqlalchemy.org/en/20/orm/basic_relationships.html#many-to-many

    Чего не хватает?

     
  • 3.96, penetrator (?), 07:45, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины

    это как со сломанными часами, которые показывают правильное время 2 раза в сутки

     
     
  • 4.126, Прохожий (??), 20:56, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины

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

     
     
  • 5.128, penetrator (?), 21:18, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
    > Есть, конечно. ORM с точки зрения конечной производительности системы - это часто
    > хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы,
    > чем вот эти поделия.

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

     
  • 5.147, Аноним (146), 15:36, 02/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, проблема ORM-ов не в адекватности запросов -- в сиквеле пофиг как ты написал, гадалка всё равно сделает так, как нужно, главное, чтоб логически было верное выражение, а у ОРМов с этим более-менее. У ORM-ов просто много накладных расходов. А сейчас ещё и добавляет то, что вошли в моду ормы поверх ормов и поверх ормов. В  той же java сейчас модно лепить всякую жуть над jpa.
     
  • 2.19, Аноним (19), 17:10, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    хорошо хоть АКТИВ РЕКОРД не вспомнил
     
     
  • 3.36, мимо (?), 18:25, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А что с ним не так? Можно развернуто?
     
     
  • 4.45, Аноним (45), 18:51, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если вся логика - это тупой crud, то ничего плохого в нем нет. А вот когда сложную бизнес-логику пытаются запихать в AR, начинается полная жесть.

    https://www.mehdi-khalili.com/orm-anti-patterns-part-1-active-record
    "active record gone crazy"

     
     
  • 5.95, Бывалый смузихлёб (?), 07:09, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Другое дело, что 9 из 10 проектов - аккурат круд и есть
     
  • 3.47, амоним (?), 18:56, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    может эксперт и не вкурсе, но АКТИВ РЕКОРД это собссно один из способов реализации ORM. подсказка: второй - это ДАТА МАППЕР.
     
     
  • 4.97, penetrator (?), 07:47, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а Linq provider это куда? )))
     
     
  • 5.105, Онанистмус (?), 09:37, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    LINQ это язык запросов. ORM на которую мапятся LINQ запросы это Entity Framework. Entity Framework это паттерн Data mapper, не active record.
     

  • 1.6, Аноним (6), 16:35, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А как он будет оптимизировать запрос под конкретные базы? И не только запрос, но и схему самих баз. Мне однажды пришлось паковать два поля в целое число - rowid для SQLite. По другому было бы жутко медленно. А так был жутко медленный импорт, а остальные релевантные запросы - быстры.
     
     
  • 2.8, BorichL (ok), 16:38, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
     
     
  • 3.49, амоним (?), 19:02, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    боюсь, что начинающий тут ты. оно предлагает написать руками по сути query execution plan.
    из минусов, только 2 конверсии внутри в скл, и в план обратно.
     
     
  • 4.51, BorichL (ok), 19:03, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > боюсь, что начинающий тут ты. оно предлагает написать руками по сути query
    > execution plan.
    > из минусов, только 2 конверсии внутри в скл, и в план обратно.

    Да? И какой сервер его будет выполнять?

     
     
  • 5.65, амоним (?), 20:27, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а там вариантов много... пг, мускл, мс скл и проч
    прям "в ассортименте"
     
  • 3.80, Аноним (80), 01:09, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".

    но и ты ее не осилил

     
     
  • 4.112, BorichL (ok), 14:36, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
    > но и ты ее не осилил

    Естественно, я ж тебе не начинающий!

     

  • 1.10, Golangdev (?), 16:39, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Обвязки для использования PRQL развиваются для языков Java, JavaScript, .NET, Elixir, R, Rust, PHP и Python

    Я негодую! Где поддержка Go ?!

     
     
  • 2.35, Карлос Сношайтилис (ok), 18:24, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Там прослойка элементарная - преобразование строк и прокидывание опций транслятору, даже раст не особо нужно знать.
    Прояви себя вместо негодования - набросай свою интеграцию.
     
  • 2.44, Аноним (38), 18:45, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    О чем ты? Какая поддержка? Го для хиптанов. А PRQL для нормальных людей. Они с хиптанами не связываются.
     
     
  • 3.64, Аноним (64), 20:19, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Rust
     

  • 1.12, Аноним (45), 16:41, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Каким образом это проще SQL?

    Сложность SQL в понимании реляционной алгебры, а это никакими изменениями синтаксиса не решить: тут либо понял, либо нет.

    А читается эта фигня точно сложнее, чем SQL.

     
     
  • 2.17, alin (?), 17:02, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проще чем кажется, на самом деле.
     
  • 2.18, Аноним (19), 17:07, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > читается эта фигня точно сложнее, чем SQL

    Более ущербного синтаксиса, чем у sql, представить сложно. А сабж читается легко, на уровне привычного разрабам array.filter(...).groupBy(...).filter(...).sort(...).

    Ирония в том, что sql начинался как язык для непрограммистов. Типа бухгалтеры будут напрямую вбивать запросы на английском языке. Оказалось, что язык, изначально рассчитанный для программистов, читается легче, чем тот, что рассчитывался для непрограммистов. Сравни синтаксис си и бейсика например. В си все предсказуемо, а в бейсике каждая новая функция -- это каждый раз новый синтаксис.

     
     
  • 3.21, Аноним (20), 17:11, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ирония в том что ты считаешь что твоя лапша удобнее sql.
     
     
  • 4.25, Аноним (19), 17:21, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > лапша

    лапша — это 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

     
     
  • 5.29, Аноним (29), 17:39, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Форматирование спасёт отца русской демократии!
     
  • 5.30, Аноним (28), 17:40, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Объсни что не так? Если ты не умеешь форматирование это не значит что все не умеют в форматирование.
     
  • 5.33, Аноним (4), 18:21, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Отформатировать и будет все понятно. Да, запрос очень простой. Когда попишешь запросы сложные, расхочется заменять на императивщину.
     
  • 5.43, Аноним (38), 18:44, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    навалил в одну строку черти что - чертичто и называется лапшой, а не SQL. ты путаешься.
     
  • 3.46, Аноним (45), 18:53, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    для программистов есть query builder-ы на том языке, на котором само приложение.

    Тот же SQLAlchemy ничем не хуже (и даже лучше) описанного, при этом нет никакого разделения на разные языки.

     
     
  • 4.50, амоним (?), 19:03, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    тут как раз один язык запросов и биндинги под разные языки и бд
     
     
  • 5.56, Аноним (20), 19:45, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это плохо.
     
  • 5.77, Аноним (45), 22:37, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем?
    Сколько раз в жизни приходилось переносить код query builder-а с одного языка программирования на другой? Большинству 0, кому-то, может, 1 раз за 10 лет.
    При этом query builder на том же языке, что и всё приложение, имеет очевидные преимущества как по интеграции с остальным кодом, так и по использованию инструментария.
     
  • 2.39, Аноним (38), 18:42, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В чем сложность понимания реляционной алгебры? Это что за такие сложности?
     
     
  • 3.70, амоним (?), 20:48, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну если таблиц пара - легко. а если 25 (д, агалитика, та самая), то схему данных удерживать в голове... на 24 шага слияния... сложно.
    но может есть гении..
     
     
  • 4.98, penetrator (?), 07:50, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    show tables;

    87 rows in set (0.000 sec)

     
     
  • 5.113, Аноним (4), 14:56, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    explain запроса сделай и посмотри, сколько там в плане шагов. 87 таблиц может быть из-за того, что 5 сервисов в одну базу сpут. Половина таблиц справочники. Знаем мы вас. Сколько из этих табличек содержат более 100000 строк?
    У тебя есть запросики, где ты одну и ту же табличку джойнишь чуть-чуть по-разному 3-5 раз? Колбасы из 10-20 лефт джойнов, зависящие друг от друга и от 5 иннер джойнов выше? Запросы более чем в пару экранов в высоту? Случалось ли придумывать логику запроса больше трех дней, а не за чашечкой кофе?
     
     
  • 6.120, penetrator (?), 20:09, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    я же не долбаеб делать такую убогую структуру базу данных, чтобы потом костылить... большой текст свёрнут, показать
     
     
  • 7.135, Аноним (117), 15:25, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Короче наплодили сущностей, данных у вас толком нет, запросы простые. Понтов много :)
    У меня стабильно проекты, где больше 100 только основных сущностей, а всякие связи вообще никто не считает.
    >это не маст-хэв

    Начальству как будешь объяснять, что им на самом деле не нужны эти данные/отчеты/аналитика?
    >какая разница, это таблица на 100 тыс, 5 тыс, или вообще очищаемая очередь?

    С таблицами на 5 тысяч можно писать в принципе любые запросы и ничего тормозить не будет, с 100т уже требуется думать головой, а когда часть таблиц имеет миллионы и десятки миллионов строк, уже приходится как-то изворачиваться.
    Понятно, если ты г-кодишь новые проекты, ты никогда не увидишь ничего подобного. Пустые таблицы, не усложненная нюансами практики бизнес-логика, аналитики нет или она в зачатке.

     
     
  • 8.139, penetrator (?), 19:59, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    смешались у тебя кони люди в одном сообщении с логикой у тебя беда в этой бд... текст свёрнут, показать
     
     
  • 9.140, Аноним (117), 00:47, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Когда у тебя большие таблицы, помимо схемы тебе надо думать еще и о количестве д... текст свёрнут, показать
     
     
  • 10.141, penetrator (?), 20:28, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    почитай оригинальный коментарий, и что именно обсуждается нет никакой сложности ... текст свёрнут, показать
     
     
  • 11.143, амоним (?), 14:17, 01/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    человек пытается сказать, что чем объемнее таблицы, тем аккуратнее надо быть при... большой текст свёрнут, показать
     
     
  • 12.150, penetrator (?), 00:21, 03/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    уже все давно придумано, называется CASE Tools, в частности для Data Modeling и ... текст свёрнут, показать
     
  • 3.115, Аноним (45), 16:27, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да меня это тоже удивляет, но 90% кандидатов на собеседованиях валятся на простейших вопросах на join-ы.
     

     ....большая нить свёрнута, показать (24)

  • 1.16, Васян из васяна (?), 17:01, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    а где биндинги для с++ и с????????????????
     
     
  • 2.61, Анонин (?), 20:07, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тут https://github.com/PRQL/prql/tree/main/bindings/prql-lib
     
  • 2.83, Аноним (80), 01:17, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    лол, будто ты что-то пишешь на них
     

  • 1.22, 1 (??), 17:13, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    О ! Они переизобрели Natural !!! Был такой язык для СУБД ADABAS в 80х.
    50 лет и круг замкнулся.

    Ещё немного подождать и появится новый SQL "на стероидах"

     
     
  • 2.34, Аноним (4), 18:22, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У меня устойчивое дежа-вю, что лет 10 назад уже было нечто похожее.
     
  • 2.42, Аноним (38), 18:44, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Про любой язык так можно сказать. Ничего они не переизобретали.
     

  • 1.23, Аноним2 (?), 17:14, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сейчас бы делать абстракцию над абстракцией.
    И с SQL то не всегда непонятно как будет база запрос обрабатывать, а с этой штукой и по давно.
    Ну от растоманов ничего другого и не ждал.
     
     
  • 2.40, Аноним (38), 18:43, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В чем тут непонятность? И в чем не понятность как база будет запрос обрабатывать? Обрадую вас: повсюду тонна инструмнетов для анализа - и это уже давно решенная проблема (обрадую вас №2).
     
  • 2.41, Аноним (38), 18:43, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Может быть просто надо вылезти из 2002 года и начать уже опльзоваться современными инструментами?
     
  • 2.148, Аноним (146), 15:40, 02/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как будет выполняться запрос никак с SQL вообще не связано.
     

  • 1.26, 1 (??), 17:21, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да ... вдогонку к 1.22 - это будет новый микросервисный, объекто-ориентированный, с параллельной обработкой, SQL !!!
     
     
  • 2.69, амоним (?), 20:40, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    как будто это что-то плохое
     
     
  • 3.103, 1 (??), 09:21, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты, наверное, любитель стимпанка.
     

  • 1.54, ИмяХ (?), 19:41, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хороший язык. На нём можно даже ОС написать.
     
     
  • 2.55, Аноним (20), 19:44, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему никто не написал?
     
     
  • 3.71, амоним (?), 20:51, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    говорят, написали
     

  • 1.58, EuPhobos (ok), 19:58, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    PL/pgSQL - меня вполне устраивает, а мускулём или машей не пользуюсь в сложных проектах, но проект выглядит интересным, нужно будет потыкать палочкой.
     
     
  • 2.149, Аноним (146), 15:42, 02/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Процедурки над сиквелом, кроме Оракла, везде плохо. В Слоне тоже. Использовать можно только строго для реализации констраинтов или простейших триггеров.
     

  • 1.62, Bob (??), 20:11, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    переизобрели 1с?
    --
    для разового запроса, оно, возможно, подойдёт. но если юзер идийот - то сервер ляжет нахер...
    --
    а вообще - нехер каждой амёбе давать доступ к базе. знание sql - как тест на профпригодность: можно к отдельным строкам r\o давать и организовать несколько шаблонов запросов)
     
     
  • 2.67, амоним (?), 20:35, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    угу, а потом отгребать нетестируемые баги из-за смеси непонятно каких подзапросов, и sql injection, потому, что подставили, ой, нитуда и нито, и ниправерили.
     
  • 2.73, C00l_ni66a (ok), 21:36, 26/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да какой 1С, он вообще на всяких кассиров пятьорочки рассчитан и хотя бы концептуально (ЯП для непрограммистов) смысл имеет. А это - попытка впихнуть ещё один слой абстракции над и так очень абстрактной шелухой, типичный пример поделия от последователей карго-культа.
     

  • 1.76, Tron is Whistling (?), 22:27, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    PR QL - в названии вся суть.
    Такое ощущение, что ребятам от моднявок даже в SQL сложно.
     
  • 1.79, Аноним (79), 01:03, 27/07/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     
  • 1.99, Простоник (ok), 08:39, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    SQL -  декларативный, PROL  - не декларативный, не процедурный и не объектный.
    А программисты любят ORM - из объектов ходят в SQL. Это как раз понять можно, автоматические методы CRUD многим нравятся.Хотя даже такое нужно с осторожность использовать.Проблемы с производительностью таки бывают. ORM API есть для C++,Java,Python.
    Для чего здесь не объектный PROL и где его место?
     
  • 1.104, Пряник (?), 09:31, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Аналитические запросы - это когда запрашивают отдельные огромные столбцы и сразу с аггрегацией. Это не про релационные базы данных, где всё строками. А какая вообще аналитическая БД использует SQL?
     
     
  • 2.110, Простоник (ok), 13:48, 27/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Apache Phoenix
     
  • 2.132, ptr (??), 07:24, 28/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ClickHouse
     
  • 2.144, амоним (?), 14:26, 01/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    например Vertica
     

  • 1.106, Анонимчик (?), 10:05, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А уже есть такой язык, наз-ся "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)

     
  • 1.108, yilativs (?), 13:37, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Выглядит прилично, посмотрим, что из этого выйдет
     
  • 1.111, vitalif (ok), 13:55, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не взлетит. Можете скринить

    Я подобную поделку лет 15 назад делал, потом понял что это нафиг никому не нужный мусор

    А в классических книжках был QUEL. И тоже его что-то никто не юзает

     
  • 1.116, 3draven (ok), 16:36, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они сделали версию Mule DataWave? У мула эта штука очень удобная, но применимая к абсолютно любому потоку данных например из сети.
     
  • 1.133, ptr (??), 07:36, 28/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я только не понял:
    - как тут с оконными функциями жить, вроде LAG, LEAD и т.п.?
    - как сюда GROUPING SETS прикрутить?
    - как APPLY/LATERAL описать?
    - как с интервалами, диапазонами и массивами этим работать?
    - как динамический SQL этим формировать?

    Короче, больше вопросов, чем ответов. Этой шняге еще годы и годы расти до возможности практического применения.
    Можно, конечно, добавить его, как еще один процедурный язык в PostgreSQL. Но толку?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру