Logica — нова мова програмування від Google для маніпулювання даними, що компілюється в SQL

Компанія Google представила нову декларативну мову логічного програмування Logica. У назву лягли слова Logic («Логіка») та Agregation («Агрегація»). Logica призначена для маніпулювання даними, компілюється в SQL та доступна для запуску в Google BigQuery, а також в СУБД PostgreSQL і SQLite, підтримка яких поки є експериментальною. Число підтримуваних SQL-діалектів планують розширити у майбутньому. Код проєкту написаний на Python і опублікований під ліцензією Apache 2.0.

Для запуску в BigQuery вам знадобиться проєкт у Google Cloud. З ним ви зможете вказати ідентифікатор проєкту та запускати програми Logica в CoLab. Для локального запуску Logica вам знадобиться Python3.

Щоб ініціювати виконання предикатів Logica з командного рядка, вам знадобиться bq (інструмент командного рядка BigQuery). Для цього необхідно встановити Cloud SDK.

Logica продовжує розвиток Yedalog — іншої мови від Google, яку випускали раніше. Нова мова надає рівені абстракції, недоступні в штатному SQL. Logica можна використовувати з інтерактивної оболонки Jupyter Notebook, також у ній підтримуються модулі та операції імпорту.

Наприклад, для формування звіту по персонах, яких найчастіше згадували в новинах у 2020 році, можна використати таку програму мовою Logiсa для запиту до БД GDELT:

   @OrderBy(Mentions, "mentions desc");
   @Limit(Mentions, 10);
   Mentions(person:, mentions? += 1) distinct :-
     gdelt-bq.gdeltv2.gkg(persons:, date:),
     Substr(ToString(date), 0, 4) == "2020",
     the_persons == Split(persons, ";"),
     person in the_persons;

   $ logica mentions.l run Mentions
   +----------------+----------------+
   |     person     | mentions_count |
   +----------------+----------------+
   | donald trump   |        3077130 |
   | los angeles    |        1078412 |
   | joe biden      |        1054827 |
   | george floyd   |         872919 |
   | boris johnson  |         674786 |
   | barack obama   |         438181 |
   | vladimir putin |         410587 |
   | bernie sanders |         387383 |
   | andrew cuomo   |         345462 |
   | las vegas      |         325487 |
   +----------------+----------------+

Logica дозволяє не витрачати багато часу на довгі запити в SQL. Вона дозволяє компонувати програми з невеликих, зрозумілих і доступних для повторного використання логічних блоків, які можуть бути протестовані, пов’язані з певними іменами та згруповані в пакети, доступні для використання в складі інших проєктів. З Logica можна використовувати синтаксис математичної логіки висловлювань, а не англійську. Це дозволяє спростити вираз складних запитів і в цілому поліпшити класичний синтаксис програмування.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

еще один проклятый ОРМ для неспособных осилить SQL

gdelt-bq.gdeltv2.gkg(persons:, date:)
Котик по клавиатуре походил?
Компанія Google представила

Реальність: Evgeny Skvortsov із Google представив нову програмування, яка ніякого відношення до гугла не має:

This is not an officially supported Google product

нєє... Ну SQL прям читається. А в цьому всьому логіки не вистачає.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Оно конечно программист к любому синтаксису привыкает. писал-читал и на ассемблере. И на М (MUMPS) однобуквенными операторами.
Регеспы те же, нечитаемы, но все же, при сноровке и пишутся и читаются. пока не очень завернуты конечно :)

но приведенный пример — это ж просто какая безвкусица. Какой-то винигрет из обломков лего, транзисторов с диодами и гальки с пляжа.

и в 21ом веке делать такой «новый» ЯП который как будто автор не знал о самой идее — синтаксис ЯП желательно приближать либо к естественному языку либо к мат. нотации.
И точно — он должен выглядеть цельно, пусть это Brainfuck...

винигрет из обломков лего, транзисторов с диодами и гальки с пляжа

Добре сказано!

gdelt-bq.gdeltv2.gkg(persons:, date:)
Котик по клавиатуре походил?

...
This is not an officially supported Google product.

Чорті-шо! І збоку бантік! :-)
1 — А главное какую проблему решает? Еще один орм? Спасибо их уже хватает.
2 — Помогать неосиляторам sql? А дальше шо? Кто будет тюнить эти сгенерированые бог знает как запросы? Кэш квери план? Индексы?...
Вобщем, тем кто осили sql оно не надо и это лишняя прослойка с еплей при сборке, отладке, деплое, профилированию.
Тем кто не осили обычный sql не поможет решать проблемы связанные с базой, а генерить по бырику запросы в базу умеют отлаженные 100500 раз энтити гибернейт и прочие другие легковесные орм...
И это...не забываем что орм это не просто генерить запросы а еще и кэш, транзакции, интеграция с юнит оф ворк и прочие штуки которые могут быть полезны при построении DAL на сервере...Здесь что? Просто язык? Чем обычный сиквел не угодил, если не пихать туда то, что должно быть на api сервере, то он просто окуенен в плане читабельности...

Какой нафиг индекс в BigQuery? Партиции и кластеризация — все твои варианты для уменьшения объёма сканируемых данных.

А какой SQL является аналогом этой хрени?

   @OrderBy(Mentions, "mentions desc");
   @Limit(Mentions, 10);
   Mentions(person:, mentions? += 1) distinct :-
     gdelt-bq.gdeltv2.gkg(persons:, date:),
     Substr(ToString(date), 0, 4) == "2020",
     the_persons == Split(persons, ";"),
     person in the_persons;

   $ logica mentions.l run Mentions

# Define natural numbers from 1 to 29.
N(x) :- x in Range(30);
# Define primes.
Prime(prime: x) :-
  N(x),
  x > 1,
  ~(
    N(y),
    y > 1,
    y != x,
    Mod(x, y) == 0
  );

Надо поставить еще 100500 пакетов из npm чтобы профилировать и экстеншенов чтобы затюнить запрос.

Которые подтянут зависимости, которые блочат работу текущего софта. Но вам про это не скажут — а чё, вы должны были успевать читать комменты, выпадающие в процессе инсталла (но в лог этого не напишут). Про это вы узнаете, когда система больше не поднимется после перезагрузки. В новогоднюю ночь.

Да кто знает?) Но я так понял, оно генерит SQL, покажите мне этот SQL, может станет яснее о чём речь.

Выводит простые числа из указанного интервала

це друга хєрня, навіщо вона в контексті тієї квері про mentions, мені не дуже зрозуміло.

какой-то перебор со знаками препинания в этом вырвиглазном синтаксисе

Та давайте вже напряму в машинних кодах писати. Ну а чо, ехфективно ж. А те що потім код не читається людиною — та кого це має хвилювати. Точно не чукча-пейсателів фреймворків класу «виніпанімаєтє етодругоє»

тю, пролога з невеликим прошарком для цього більш ніж достатньо, нащо городити оце пітонієве подєліє, тим більше, нашо впрягати туди аж цілого гугла, який там ні сном, ні духом?

еще один проклятый ОРМ для неспособных осилить SQL

нєє... Ну SQL прям читається. А в цьому всьому логіки не вистачає.

Хрень и говно.

(persons:, date:)
:-

Это типа бл@ть хороший синтаксис?

Я лучше SQL попишу.

Самое хреновое то, что хипстота и на него подсядут, потому что новое, и какойто 23-летний задрот-рахитектор обязательно, сска, втянет это говно в проект.

Хуже: следующие лет 15 это дерьмо придётся знать чтобы иметь возможность работать с наследием. Равно как и все обходы недопиленных багов.

Компанія Google представила

Реальність: Evgeny Skvortsov із Google представив нову програмування, яка ніякого відношення до гугла не має:

This is not an officially supported Google product

З одного боку — чисто тобі Пролог: предикати, синтаксис, оці всі коми та :-

З іншого — оця умора

Substr(ToString(date), 0, 4) == "2020",
the_persons == Split(persons, ";"),
Типу даних «дата» нема?
А «==» - це bind-оператор?
Бо у 1 рядку це явно порівняння як одна з умов предикату, а у 2-му — присвоєння, ібо the_persons вище по тексту не зустрічається

Вони серйозно збираються це просувати?

Хочеться модульності — он у дідуся Дейта є мова Tutorial D, її можна було б довести до розуму...

З Logica можна використовувати синтаксис математичної логіки висловлювань, а не англійську.

Це прикольно, але що це за синтаксис, чи потрібно його окремо вивчати, чи може практика сама наведе на формат мислення для даної мови запитів?

Prolog же, изи. Непонятно только насколько полно реализованный и насколько быстрый.

фігня. знов сову на глобус натягують ))) sql нам подобається тим, що він для людини зроблений, а тут знов якусь orm-щину намагаються продати

Одні умови пиши в where, інші в having, якщо переплутаєш — SQL сервер пошле тебе, а значить знає де що має бути. Але чому тоді сам не розставляє? Такий от дружній до людини ;-)

І все одно написати щось ніби-то просте на SQL-і складно. Два-три джойни — і кверя вже не читабельна.

І все одно пише квері людина обмежений час, а потім ранаються вони довший час автоматично софтом — і толку з того псевдо human readbility вже немає, але щоб все це було efficient треба prepared statement-и — бо парсити квері кожен раз накладно. А різинх запитів в будь-якому серйозному софті багато...

Тобто оце вам читабельно? )))

   @OrderBy(Mentions, "mentions desc");
   @Limit(Mentions, 10);
   Mentions(person:, mentions? += 1) distinct :-
     gdelt-bq.gdeltv2.gkg(persons:, date:),
     Substr(ToString(date), 0, 4) == "2020",
     the_persons == Split(persons, ";"),
     person in the_persons;

якщо хтось не користується prepared statement’ами, то це привід дати йому канделяброю.

А от якщо я прийду до вас налаштовувати запити і побачу нечитабельну хтонь, то канделябром вже отримаєте ви ;-)

Для багаторядкових блоків коду більше підходить тег pre.

якщо хтось не користується prepared statement’ами, то це привід дати йому канделяброю

Ви не зрозуміли суть коментаря.

А от якщо я прийду до вас налаштовувати запити і побачу нечитабельну хтонь, то канделябром вже отримаєте ви ;-)

Це погроза?

ні, це такий жарт в мене

Если вы бы хотя бы немного программировали на Prolog-е, то легко прочитали бы.

В том то и проблема, что SQL везде, а для изучения этой фигни нужно предварительно выучить еще и пролог.

пролог треба просто вивчити, а не для цієї фігні

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

пролог чи даталог читати легше, і головне, неясно нащо його міняти на оце

Если вы бы хотя бы немного программировали на Prolog-е

А якби на Perl норм так попрограмували і перейшли на any мову програмування, то б «лилися сльози щастя щоночі»

На кой пес пролог склющикам и джавистам/дотнетичка? Если жто аля орм для пистаелей на прологе то ноу проблем. Остальные кто возится с базой, на кую вертели сей пролог.

Ну есть графовые базы данных, где есть Prolog-like языки запросов, что вполне естественно. Ну и если мы говорим о базах данных, то, ИМХО, полезно знать, что есть и другие вариант запросов, которые в некоторых случах подходят лучше SQL, даже несмотря на наличие иерархических запросов CONNECT BY, NOCYCLE и т. п.Так что не думаю, что это настолько уж лишнее знание.

Але чому тоді сам не розставляє?

Це не входить в задачі синтаксичного парсера

кверя вже не читабельна

використовуйте відступи
Аргумент, що код складний від тайтлів більших за джун?
Хмммм

бо парсити квері кожен раз накладно

ні
Це для активізації оптимізацій ЗУБД

Це не входить в задачі синтаксичного парсера

Входить — якщо він «юзер френдлі», як стверджував автор.

використовуйте відступи

:D
Все одно будь-який мало мальский серйозний запит стає дуже verbose через громіздкий синтаксис, а тому мало читабельний. З відступами чи без.

ні
Це для активізації оптимізацій ЗУБД

Тобто уникнення повторного парсингу SQL сервером це не оптимізація? А що це? :D

Входить — якщо він «юзер френдлі», як стверджував автор.

Я боюся, що тоді туди треба буде всунути ML, дуже багато ML

мало читабельний

*складно читабельний

Тобто уникнення повторного парсингу SQL сервером це не оптимізація?

Вам краще дізнатись, як цей процес відбувається в вашій ЗУБД
Щоб не виникало таких питань

Претензій до sql повно, тіки вони не ті що ви навели

Вам краще дізнатись, як цей процес відбувається в вашій ЗУБД
Щоб не виникало таких питань

Так просвітіть нас — які такі оптимізації застосовуються лише до prepared statement-ів? Крім очевидного про яке я написав — уникнення повторного парсингу.

Претензій до sql повно, тіки вони не ті що ви навели

І ті в т.ч.
Юзер-френдлінес SQL-ю дуже умовна. Якщо треба дати якимось аналітикам на боці кастомера можливість кверяти і аналізувати дані — ніхто при здоровому ґлузді не видасть їм SQL (хоча здавалось би — які проблеми, просто заборонити write, нехай мають read only права і доступ лише до бази з тими даними, які їм потрібно аналізувати). Бо клієнт за таке нафіг пошле.

Тому городять всі свої якісь велосипеди замість цього.

Так просвітіть нас

www.postgresql.org/docs/10/sql-prepare.html ?
З мене поганий вчитель

Якщо треба дати якимось аналітикам на боці кастомера можливість кверяти і аналізувати дані

Я не впевнений, що можна назвати людину аналітиком, якщо вона не знає sql чи інший яп, якщо вона працює зі специфічним софтом

Для умовно-аналітиків, що працюють в екселі — тут простих рішень нема

Тому городять всі свої якісь велосипеди замість цього.

Якщо питання про CRUD, то так ORM — наше все

Він погано працює, коли в нього пхають 100гб рав дата

ОРМ мавпочки дешевші та слухняніші
але не дуже розумні, раз селект написати не спроможні

ОРМ мавпочки дешевші та слухняніші

Пардоньте, але не трогайте ОРМ. Без нього у мене б роботи не було.

www.postgresql.org/docs/10/sql-prepare.html ?
З мене поганий вчитель

А самі ви читали що запостили? „the main point of a prepared statement is to avoid repeated parse analysis and planning of the statement”

Так і для не-prepared statement-у будується план. Весь бенефіт лише в тому що це не потрібно робити повторно — як і в випадку з парсингом.

Ви взагалі розумієте що ви намагаєтесь довести?

Мабуть треба було з самого початку сказати
Синтаксичний парсер — виконується швидко
Планування — довго робиться
І в контексті оптимізації великих і складних запитів, більше економії приходиться на плануваня аніж парсинг

Синтаксичний парсер — виконується швидко
Планування — довго робиться

Це сказав вам хто? Але нехай.
Все одно все зводиться до повтороного використання.

І доречі, планнер може краще відпрацювати коли є значення параметрів — що не можливе в prepared statement-ах. Тому ваше твердження що існують якісь оптимізації, які відбуваються лише для prepared statement-ів не відповідає дійсності — навпаки, є оптимізації по значенням параметрів які неможливо застосувати до prepared statement-ів, бо там значення параметрів змінні.

P.S. І хто вам сказав що всі сервери кешують плани лише для prepared statement-ів, але не для dymamic SQL запитів? MS SQL Server наприклад кешує обидва — цитую: " the query is dynamic sql or prepared, the compiled plan is stored in the SQL Plans (CACHESTORE_SQLCP) cache store"*, тому які оптимізації ще відбуваються лише для prepared?

* - techcommunity.microsoft.com/...​ached-objects/ba-p/383203

воно то закешує (якшо не буде явних або неавних причин для рекомпайлу)
але дурь людська безмежна
чи буде план використано повторно і скільки планів та запитів буде згенеровано це питання

Одні умови пиши в where, інші в having
написати щось ніби-то просте на SQL-і складно. Два-три джойни — і кверя вже не читабельна

а ти точно senior та tech leader?

а ти точно senior та tech leader?

Точно. А хто запитує?

да сомнения есть.
Синьор для которого 2-3 джойна «нечитабельны» это какойто синьор курильщика.

Надо на Entity framework или Hibernate все делать, гигантский SQL, особенно гигантские процедуры с бизнес логикой в 2k21 это не признак большого ума, а признак быдлокода.

Бывают ситуации, когда лучше написать JPQL

EF зло
про хибернейт не знаю но подозреваю

Для мене персонально немає проблем написати SQL чи Logica, це якраз автор коментарю жаліється що Logica не читабельна — а SQL «для людей».

Але якщо він «для людей» — то дайте його своїм клієнтам як інтерфейс до вашого рішення, і швидко взнаєте який він «для людей».

Ви не зрозуміли посилу, а лише випендрюєтесь «а синьору скуль легкий, ты шо ни синьор?».
Ну — хто що вміє. Кому розуміти — а вам випендрюватись.

Але якщо він «для людей» — то дайте його своїм клієнтам як інтерфейс до вашого рішення, і швидко взнаєте який він "для людей«.

Ты постишь какие-то совершенно детские аргументы.
Домохозяйка твоей «читабельной логике» тоже нихрена не обрадуется.
Но девелоперы и аналитики предпочтут SQL.

Домохозяйка твоей «читабельной логике» тоже нихрена не обрадуется.

:facepalm:
Якраз Logica не є читабельною і не прикидається такою. На відміну від SQL — який теж так собі читабельний, але super verbose.

И в чем же он вербоз?
А, кроме того, в сиквеле нет этого пидарства со знаками препинания, которое почему-то суют везде разные хипстеры.
Вот нахера вот эта дрочь :- ?
Введите бл@ть кейворд! Нет, сска, мы при разработке напихаем в синтаксис разного визуального хлама
@var: =÷ # ? operator* +> func%()
Ахиреть как крутаа! Пойду напишу такую функциональную библиотеку для логики с аспектами реактивного программирования на питоне с транспиляцией в джаваскрипт чтобы обрабатывать бигдату прямо в хроме на макбуке! И возможностью вставлять скрипты на скале. Щас только усы от смузи вытру.

А ти читав цю статтю чи просто назва сподобалась?
Там викладені цілком логічні думки, де і у яких аспектах SQL програє і для будь кого, хто хоч трохи пописав запитів на SQL, багато аргументів зайдуть.
Тим не менше, це не відміняє того, що яким би відсталим SQL не був (родом із 70-х, на хвилинку), ця річ із топіка не має жодної переваги над ним.

До речі, ця стаття scattered-thoughts.net/writing/against-sql — це інтро для персонального проекту її автора, який намагається зліпити кращу мову для реляційних запитів. Як на мене, похвальне зайняття, може щось і вийде.

Тикати бомжам в підворотнях будеш, хамло.

Переваги Logica над SQL описані в ресурсах самого Google, але звичайно кожен формошльоп в Україні знає краще за девів з Google що має переваги, а що ні.

Зрозуміло, питань більше нема.
Каргокультизм перед «гуглами» + несамовите бажання щоби до тебе «викали» — велика річ, продовжуй далі.

Два-три джойни — і кверя вже не читабельна.

Бред.
Надо просто форматировать запросы а не валить все ловеркейсом в одну строку.

Скопіюю свій коментар з іншого треду

Юзер-френдлінес SQL-ю дуже умовна. Якщо треба дати якимось аналітикам на боці кастомера можливість кверяти і аналізувати дані — ніхто при здоровому ґлузді не видасть їм SQL (хоча здавалось би — які проблеми, просто заборонити write, нехай мають read only права і доступ лише до бази з тими даними, які їм потрібно аналізувати). Бо клієнт за таке нафіг пошле.
Тому городять всі свої якісь велосипеди замість цього.

От кастомеру свойому скажіть «ти просто форматуй квері»

Ну копию данным им для репортов
И посматривать за особо вредными

Копію даних? А якщо це телеком чи великий рітейл, і даних там пів петабайта?

1. Если «аналитики кастомера» не знаю сиквель то это говно а не аналитики. Все аналитики здорового человека которых я видел умели в сиквель не хуже девелоперов.
2. Если им не подойдет сиквель — и не подойдет _никакой_ другой язык.

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

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

По моему опыту, вторые, на стороне кастомера обычно, дадут фору в скл многим программистам.

Я вибачаюсь, але переплутати where і having це ще треба постаратися. Це місія для «обдарованих» людей.

І все одно написати щось ніби-то просте на SQL-і складно. Два-три джойни — і кверя вже не читабельна.

А. Ну тоді питань немає.

Два-три джойни — і кверя вже не читабельна.

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

якщо переплутаєш —

Дальше не читай
Там еще group by есть
Он п***ит псевдо сеньеров плюшевым зайцем

Тобі дісталось? Бідака

EPAMу варто вiдdищити вас до ліда
(з переатестацією на SQL)

А вам варто перечитати коментар щоб зрозуміти суть.

Мені персонально що Logica що SQL — монопенісуально. Але кастомерам я би SQL як інтерфейс не видав, бо зовсім не такий він «юзер френдлі» як вважається.

Виходить що SQL і не експрессів достатньо, і не юзер френдлі достатньо, якось ні там ні там. Невтаємниченим його не довіриш, а втраємниченим нафіг не впало розписувати псевдоінглішем кілометрового розміру квері, де кожен зв’язок виражається через verbose конструкцію tableA [kind] join tableB on tableA.columnX = tableB.columnY, через що два-три джойни роблять кверю тупо довгою і в результаті нечитабельною через непотрібний verbosity.

SQL попадає в таке собі limbo — ні тим ні тим.

Тобто, кверя «тупо довга», а оце полотно на Logica — буде коротшим, я правильно розумію? Цікаво було б побачити як виглядатиме рішення на Logica для якоїсь з учбових задач, хоча б звідси — www.chegg.com/...​o-sname-status—q24502234

тот случай когда +2 см не неимущество

Тобто, кверя «тупо довга», а оце полотно на Logica — буде коротшим, я правильно розумію?

Там полотно через якусь лабуду з датами через сабстрінги. Так було б коротшим.

Так я без всяких дат пропоную знайти рішення для задачі, наприклад:
6.Print supplier names for suppliers who do not currently ship any parts.
Або для такої задачі (з зірочкою):
Print supplier name pairs who ship exactly same list of parts.

А чому без дат? Це що за задачі — з якої дупи витягнуті? Візьміть щось реальне. У вас є ті ж таблиці supplier, shipment, parts — але в кожного shipment-у є дата. А тепер вам задачка — відобразити не супплаєрів без шіпментів (це що за ідіотія взагалі? наперед відомо що вони є — тільки треба їх знайти? В житті наперед нічого цього НЕ відомо — задача настільки синтетична що аж пластиком смердить), а за заданий період (від заданої дати початку до заданої дати кінця) відобразити кількість шипментів пер сапплаєр з групуванням по датам за заданий період (день, тиждень, місяць, квартал, рік), додатково з розбивкою по запчастинам. З врахуванням таймзони кастомера яка відрізняється від таймзони сервера (і день в кастомера починається не тоді, коли день починається на сервері).

На додаток — нехай кожен сапплаєр і парт має теги, і треба ще фільтрувати або групувати по окремим тегам (приклад тегу — business unit).

Оце реальна задача, дуже типова. Напишіть на SQL відповідні квері і скажіть, що вони прості і не verbose.

А ви взяли замість реальних задач синтетичне чортзнащо, зроблене навмисне під SQL — і намагаєтесь на їх прикладі довести перевагу SQL над Logica? Це дуже примітивна маніпуляція.

)) да будь-яка задача підійде, яка різниця?) що таке «розбивка по запчастинам»?) Таймзона вирішується типом timestamp with timezone — ваш кеп)
для різних періодів буде щось подібне — в даному випадку це кверя, яка може бути упакована в процедуру з параметрами, для «фіксованих» і різних періодів групування (в прикладі 2 години, 12 годин і 1 день), якщо потрібні конкретні інтервали, можна передавати окремі дати початку і кінця, це ще простіше.

select      
          CASE
           WHEN in_group_interval = '1W'
           THEN
            date_trunc('hour', ship_ts) - (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 2) * interval '1 hour'
           WHEN in_group_interval = '1M'
           THEN
            date_trunc('hour', ship_ts) - (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 12) * interval '1 hour'
           ELSE
            date_trunc('day', ship_ts)
         end as group_ts
    from shipment
    where ship_ts > current_timestamp -
       CASE
          WHEN in_group_interval = '1W'  THEN interval '1 week'
          WHEN in_group_interval = '1M'  THEN interval '1 month'
          WHEN in_group_interval = '1Q'  THEN interval '3 month'
          WHEN in_group_interval = '1Y'  THEN interval '1 year'
        end
Так все-таки, як подібна частина квері буде виглядати в Logica? Можете показати?
Я просто додам — ця кверя вже є підготовленою для групування, далі потрібно тільки додати інші параметри групування і самі функції групування, тобто загальна кверя буде виглядати не складніше ніж ця. А як аналогічна буде виглядати в Logica, знову ж таки, можна побачити?

Не враховує таймзони. date_trunc відсутній взагалі в MySQL наприклад (see dev.mysql.com/...​e-and-time-functions.html ).

Доречі деякі таймзони зміщені на пів години відносно UTC.

що таке «розбивка по запчастинам»?)

Запчастини тут в таблиці part. Part це запчастина.

Типова задача — bar chart (стовпчикова діаграма) де кожен стовпчик ще всередині розбитий на підгрупи (e.g. chartio.com/...​stacked-bar-example-1.png )

Треба брейкдаун або по part, або по якомусь тегу на supplier.

Оця неробоча похабщина з case-ами (неробоча бо таймзони) — вона звичайно дуже читабельна. Можливо в Logica вийде не сильно краще — нехай, але вже точно і не сильно гірше ніж в «читабельного» SQL, який не verbose і для людей.

Таймзона вирішується типом timestamp with timezone — ваш кеп)

Ви не зрозуміли нічого :facepalm:
В кожного користувача буде СВОЯ ТАЙМЗОНА. Вона НЕ ЗБІГАЄТЬСЯ з якоюсь ОДНОЮ таймзоною серверу.

Юзер який зайшов з США з іст кост має побачити в EST всі дати, а юзер з України — в нашій таймзоні.

В кожного користувача буде СВОЯ ТАЙМЗОНА. Вона НЕ ЗБІГАЄТЬСЯ з якоюсь ОДНОЮ таймзоною серверу.

ОБОЖЕ, у кожного користувача своя таймзона, який жах!) Відкрийте для себе конвертацію у клієнтську таймзону, яка буде робитись по-різному в різних СУБД звісно.
Ще раз, таймстампи з таймзоною вирішують будь-які проблеми, в тому числі і конвертацію (тим більше, що зберігається все в UTC все одно в разі використання timestamptz, наприклад). Конвертація при читанні у випадку Postgre буде робитись в запиті, в процессі вставок така конвертація проходить автоматично.
Або в тому ж самому Oracle є такий тип — TIMESTAMP WITH LOCAL TIME ZONE, спеціально для таких випадків, і тут взагалі навіть не потрібно нічого конвертити, все конвертиться автоматично і при додаванні значень, і при читанні.
Те що Ви про це ні сном ні духом, зовсім не означає що цього немає.

Типова задача — bar chart (стовпчикова діаграма) де кожен стовпчик ще всередині розбитий на підгрупи

ОБОЖЕ, яка складна задача!
Відкрийте для себе grouping sets може?)
Так я побачу хоч якийсь приклад з Logica?

яка буде робитись по-різному в різних СУБД звісно

SQL — такий корисний стандарт. Дати? Ні, це якась рідкісна штука — не достойна стандарту :facepalm:

Конвертація при читанні у випадку Postgre буде робитись в запиті, в процессі вставок така конвертація проходить автоматично.

Це коли таймзона береться per connection? До дупи це — різні юзери будуть реюзати різні коннекшни до бази, коннекшни практично завжди pool-аються і реюзаються.

Тому ніякий автоматизм тут не світить.

Або в тому ж самому Oracle є такий тип — TIMESTAMP WITH LOCAL TIME ZONE

А в MySQL є такий? :-)

ОБОЖЕ, яка складна задача!

Якщо вона така проста — чому ви видали оце потворство на 15 лінійок? Це не verbose? Це clear and concise?

«date_trunc(’hour’, ship_ts) — (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 12) * interval ’1 hour’»
Така похабень це норм, а Substr(ToString(date), 0, 4) == «2020» в прикладі це «ужос ужос»? Зрозуміло.

Це коли таймзона береться per connection? До дупи це — різні юзери будуть реюзати різні коннекшни до бази, коннекшни практично завжди pool-аються і реюзаються.

ну не можна ж так фейспалмити) зміна локальної таймзони — це один стейтмент, який буде виконуватись на рівні сесії після взяття з пулу конекшена.

А в MySQL є такий? :-)

Я не знаю як в MySQL, але півхвилини гугління дають це:
«Have the client specify its time zone when it connects to the server by setting the time_zone system variable.»
«MySQL interprets TIMESTAMP values with respect to each client’s time zone. When a client inserts a TIMESTAMP value, the server converts it from the time zone associated with the client connection to UTC and stores the UTC value. (Internally, the server stores a TIMESTAMP value as the number of seconds since 1970-01-01 00:00:00 UTC.) When the client retrieves a TIMESTAMP value, the server performs the reverse operation to convert the UTC value back to the client connection time zone.»
www.oreilly.com/...​d/059652708X/ch06s04.html

Це не verbose? Це clear and concise?

«date_trunc(’hour’, ship_ts) — (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 12) * interval ’1 hour’»

Я зараз процитую:
«Ви не зрозуміли нічого :facepalm:»
Це тільки у випадку якщо змінюється «грануляція» для групувань. Якщо для кожного інтервалу потрібне групування по днях, то ясно що нічого з цього не потрібно, там буде тільки date_trunc(’day’, ship_ts). Тобто весь запит буде декілька рядків, включаючи grouping sets.
Цей же запит в Logica буде в кілька разів довшим, я вже не кажу про те що його неможливо буде зрозуміти. А якщо додати можливість різної грануляції інтервала групування, то таке мабуть неможливо написати в Logica в принципі.
Але рівень Ваших знань в SQL вже зрозумілий, дякую)

один стейтмент, який буде виконуватись на рівні сесії після взяття з пулу конекшена

Це якщо коннекшни руками брати і на коннекшнах виконувати квері — що ніхто не робить, бо завжди є більш високорівневий API над цим всім.

Я не знаю як в MySQL, але півхвилини гугління дають це:
«Have the client specify its time zone when it connects to the server by setting the time_zone system variable.»

Повторюю — це дуже паршивий варіант, ще раз повторюю — коннекшни до бази пулаються, їх треба реюзати. Доведеться городити костилі навколо цього.

Вже не кажучи про те, що ці фічі працюють у всіх СУБД по різному — бо в стандарт SQL вони не входять. Тому наявність якогось костилю в MySQL не означає що в SQL все ок.

Більше того, часто люди пишуть ще автомейтед тести на квері, і замість того ж MySQL підпихують якусь in-memory СУБД для тестів (аля H2) — і тут все летить в одне місце, бо те що працювало для MySQL в H2 не працює (особливо те що стосується дат — навіть елементарщину типу UNIX_TIMESTAMP в H2 доводиться додавати костилем).

Але ж там кругом SQL. От тільки стардарт такий, що це нікому не допомагає.

Це тільки у випадку якщо змінюється «грануляція» для групувань. Якщо для кожного інтервалу потрібне групування по днях, то ясно що нічого з цього не потрібно, там буде тільки date_trunc(’day’, ship_ts).

Чому раптом ні? День то в кожній таймзоні починається в різний час.
Але так, агрегація може бути не тільки по дням а і по годинам.

А ще потім до цього всього додається фільтрація по таблицям які приджойнені (аля теги), і тоді оця мила кверя на 15 лінійок виростає ще вдвічі.

рівень Ваших знань в SQL вже зрозумілий, дякую)

А, так вам це важливо? Ок, давайте так — нехай я повний нуль в SQL. Коли вас це робить щасливим — нехай я повний нуль у абсолютно всьому і взагалі ніхто. Далі що? :-)

Все одно ви своїми ж дописами довели що SQL зовсім не читабельний стає при вирішенні цих досить таки типових (і здавалось би тривіальних) задач. Що і треба було довести.

Все одно ви своїми ж дописами довели що SQL зовсім не читабельний стає при вирішенні цих досить таки типових (і здавалось би тривіальних) задач. Що і треба було довести.

)) На тому і розійдемось)
Мій досвід говорить мені що будь-який аналітик надасть перевагу SQL ніж чомусь подібному до Logica.
Тим більше що як ці «досить типові і тривіальні задачі» вирішуються в Logica, я так і не побачив, на жаль)

Я так розумію, що ці задачі виявились заскладними. Давайте ж візьмем ще більш просту задачу.
Є таблиця Nums (num int), всі значення унікальні в діапазоні 1-1000 приміром, але є «пропуски», треба вибрати інтервали чисел, які «пропущені» в таблиці. Це ж без джойнів взагалі, для Logica це має бути проста задача для демонстрації можливостей.

Одні умови пиши в where, інші в having

Ну да. Це ж таємне сакральне знання — одні умови для відбору з первинних даних, інші — для фільтрації готової виборки.

до речі, ми цю новину вже обговорювали в нашому чатику PostgreSQL Ukraine, починаючи з цього повідомлення: t.me/PostgresUkraine/7214

Заходьте в гості! :-)

А вот и не фигня, это концепция Дия.Сити, которая не подсилу большинству.

Ну... там всё-таки Prolog-лайк язык, который скорее детает простым то, что в SQL досаточно сложно реализуемо, типа у нас есть таблица пар вершин, найти все пути из вершины A в вершину B. Тут это 2–3 строчки кода, а в SQL застрелиться.

А это точно задачка для скл?
Хотя если проранжировать.

Вобщем рекомендую позадротить аналог сиквельного литкода
Sql-ex. Ru
Там олимпиадные задачки

Если Вы думаете, что что-то сложно, Вы просто не умеете этого делать.

А это точно не графовых базы задачка?
Напоминю что скл декларативный язык и многие вещи из обычных языков в принципе не ложатся туда читабельными и более того в плане перформанса могут быть очень не выгодными.
Вобщем — оставте скл задачи для которых он предназначен, остальное оставтье на DAL и BLL с соотвествующими и будем вам счастье.
Просто сдедалть язык который подойдет для все сразу не будет и нет смысла в нем.

Посилання «Наприклад» веде на аналогічну статтю на opennet — це так задумано?

Подписаться на комментарии