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

Логическим блоком в SQL является подзапрос или CTE и вроде бы можно разбивать запрос по блокам и работать с ними отдельно, как строится по кирпичикам любое приложение.

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

А что, если не надо писать SQL?

В SAP мы не писали запросы, мы создавали Calculation View, и работать с ними было на порядок быстрее и приятнее. 

Перефразируя диалог из Матрицы: 

- Когда я стану избранным, я смогу писать длинный SQL?

- Тебе не надо будет писать SQL.

После добавления в asapBI возможности создания моделей Data Vault (вот статья на эту тему), я переключился на реализацию Calculation View. За основу я взял логику, реализованную в SAP Hana Calculation View (анализировал также и другие построители) с добавлением новых возможностей:

- визуальное построение выборки данных

- использование параметров CV при выборе данных

- использование различных баз данных (ADB, Greenplum, PostgreSQL, Clickhouse)

- на выходе как вся CV, так и ее промежуточные блоки представляют собой функции (UDF) базы данных – их можно вызвать из других инструментов

- возможность выполнения CV как внутри базы, так и на внешних кластерах (например, Trino или CedrusData). Это значит, что трансформация данных и закрытие периода будет идти не 4 часа, нагружая продуктовую базу данных, а 10 минут на внешнем кластере. Или не потребуется материализация данных для отчетов - за ней ведь еще и следить надо.

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

- возможность отказаться от asapBI IDE и вести дальнейшую разработку общепринятыми инструментами без потери наработанного - т.е. без вендор-лока.

- использование AI.

Создать CV, как и объекты модели данных, можно в любой папке, пример созданного CV:

Кто-то скажет, что запросы можно вручную написать – это так, но ТТМ будет уже не таким.

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

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

Вишенка на тортик

 Коллеги, а зачем нам инструмент, который не сам будет работать? Весь этот выбор и создание таблиц, протягивание соединений, join по полям – разве в конце концов нам это нужно?

Нам надо, чтобы инструмент работал сам, строил запросы, модели данных, а мы проверяли решение и допиливали по мелочи неучтенные вопросы.

 В этом, конечно же, нам поможет встроенный в asapBI локальный или облачный AI. А вот как именно поможет – это уже тема отдельной публикации.

Буду рад обратной связи.

Например, чего именно не хватает в подобных построителях?

Да и вообще имеют ли такие системы смысл? Ведь писать длинные тексты на чистом SQL так увлекательно и приятно ;)