игнорирование СУБД: так как мой язык компилируется в SQL, то есть в БД летит один SQL-запрос. Это как раз принципиальный момент: я хочу создать компактный и удобный для человека язык, который при этом будет быстрым, так как будет компилироваться в SQL и выполняться как SQL.

Насчёт оптимизации — это сложный вопрос. Я уверен, что запросы, где очень важна оптимальность и которые выполняются часто и много, безусловно останутся на чистом SQL с хинтами, и автоматически я не смогу делать лучше. Но целевой областью своего языка я вижу именно аналитические запросы, которые часто выполняются всего один раз или очень редко (посмотрел интересующий меня срез, ничего интересного не увидел — пошёл дальше), и в такой парадигме, если я пишу запросы, которые будут выполняться раз в неделю, месяц или вообще один раз, но мне нужно написать их 100 разных, очень важна именно выразительность языка, а не его оптимальность.

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

уничтожение комментариев: наверное, вы про @link(pets, machines) и т. д. Это спорный момент. В свою защиту могу сказать, что таких тагов немного — не больше одного на столбец — и это не сильно мешает читать остаток коммента (на мой взгляд). Более того, часть тагов (link, id) можно добавить в виде primary/foreign key, оставшиеся можно и не указывать — просто качество модели данных станет чуть хуже. Также можно добавить возможность подгружать эту инфу отдельным файлом YAML.

Вообще спасибо большое за вопросы.

Balb Dec 10 2025 at 10:28

Проблема в том что комментарии нужны не только вам а к примеру также аналитику из соседнего отдела с негоо другой аналитической модель . Разработчику

По поводу скорости работы. Крайне зависит от объема данных и сложности выборки. Даже вас я думаю не устроит выборка формируемая в течение 50+ часов.

korbash1 Dec 10 2025 at 10:42

про коментарии тогда второй подход создать для того кто пользуется моей системой отдельную схему с вьюшками на изначальные таблицы и в этих виюшках уже будут коменты. всё равно в реальности обычно для построения ветрин данных используются инструменты типа dbt, sqlmesh и нету проблемму для каждого отделу создать свою вьюшку, для этого кст и нужен таг link тк очень часто исходники это не физические таблички а вьюшки а к ним в описание primary/foreign key уже не добавишь (зависит от бд).

Даже вас я думаю не устроит выборка формируемая в течение 50+ часов.

безусловно запрос который работает больше 5 минут уже плохо нужно думать как оптимизировать. Но тут скорее это какоето предогрегирование добавление копии таблицы с другой сортировкой если мы говорим про кликхаус. для этого используют dbt, sqlmesh. безусловно для таких вещей мой язык не подходит

MasterErik Dec 13 2025 at 17:30

Жесть. SQL самый простой и ужасный язык. За 30 лет он слабо изменился. Но все время его хотят улучшить. Так придумали orm. Теперь надо знать orm и sql. Некоторые стали считать, что sql, не надо знать. Ребята выучитье sql и не придется ничего изобретать.

ALexKud Dec 30 2025 at 12:04

Это так, но чтобы выучить SQL нужно научиться на нем обработке данных. А это считается в современном программировании антипаттерном и препятствием к масштабированию.К тому же использование ORM избавляет от необходимости глубокого изучения SQL. Вот поэтому обработка данных средствами СУБД практически не используется, хотя она дает много преимуществ в определенных задачах. Все свои разработки я делаю с использованием именно серверных средств, но у меня не web и не хайлоад. Одна такая система описана мной в статье, которую можно найти в моем профиле.

korbash1 Dec 30 2025 at 21:50

Я абсолютно согласен, что обрабатывать данные внутри БД сильно быстрее, если говорить про большие аналитические запросы. Точнее даже так: основная проблема — это транспорт данных по сети, поэтому всё, что требует обработки больших объёмов, быстрее делать внутри БД. Но тут есть проблемка, что SQL как язык для БОЛЬШИХ аналитических запросов плох (он удобен для написания простеньких скриптиков).

В дополнение к минусам, которые я перечислил в начале статьи, вот ещё 2:

плохо с переиспользованием — функции у каждого диалекта свои
нельзя разнести код по разным файлам, то есть нельзя сделать полноценную библиотеку
Супер простая вещь: логичнее был бы синтаксис FROM deals SELECT, так как на этом этапе IDE может подсказать колонки из deals, а при стандартном порядке не может.

Мне интересно, что вы думаете про эти минусы, особенно если вы считаете, что это не минусы и лучше, чем существующий SQL, сделать не получится.

ORM избавляет от необходимости глубокого изучения SQL

Тут скорее другая идея: чем больше IDE знает, тем лучше. Может подсказать возможные значения, проверить тип и т. д. Та же причина, почему сейчас все возвращаются к статической типизации даже в языках, где идея была в динамической.

Ещё одна вещь: классические ORM — это просто обёртка над SQL, они сохраняют логику SQL. У меня же новая логика: я работаю не с таблицами и колонками, а с метриками.

ALexKud Jan 12 at 09:11

Насчет простеньких скриптиков это зря вы так сказали. Если использовать хранимые процедуры, функции, триггеры и СТЕ , то можно делать очень сложную обработку данных внутри БД. Код хранимок и пр. можно разнести по разным файлам легко если хотите использовать GIT. Я использую триггеры БД для автосохранения в БД истории кода хранимок, функций и всех DML манипуляций в отдельной БД. Всегда можно откатить назад все изменения. Когда вы используете студию SQL, то вся структура БД у вас перед глазами. Типы легко проверяются в SQL. При использовании только SQL запросов функционал обработки может быть на порядок сложнее и больше чем использование обработки внутри БД. Я имел подобный опыт, когда переносил БД из SQL SERVER в локальную SQLite. Клиентская часть с SQLite получилась намного сложнее и больше по объему, когда используются только запросы и CТЕ. Счастье было и то что SQLite поддерживает CTE, иначе все еще было бы намного сложнее.

Насчет аналитических запросов для больших БД - в любом случае требуется либо мощное железо либо другой вид БД , например колоночная БД

korbash1 Jan 13 at 04:27

То, что для аналитических запросов нужна колоночная БД, — согласен, по-другому никак.

Насчёт CTE тоже согласен: это суперполезная штука, решает 90% проблем, и все аналитические БД, к счастью, её поддерживают.

Со встроенными функциями уже хуже — тут нет единого стандарта.

Про «разнести по разным файлам» тоже есть инструменты для аналитических запросов — dbt, sqlmesh.

Про использование обработки внутри БД не совсем понял, что вы имеете в виду в контексте аналитических БД. В голову приходит только AggregatingMergeTree в ClickHouse.

Вообще я согласен, что проблемы, которые есть в SQL, можно решить — в основном, используя внешние надстройки, а не чистый SQL. Собственно, я тут и предлагаю одно из таких решений: язык, программа (запрос) на котором компилируется в SQL с кучей CTE. И, собственно, моё утверждение в том, что он выразительнее и удобнее для аналитических запросов, чем SQL с CTE и UDF.

Про изучение структуры БД через SQL Studio и аналоги — это, конечно, хорошо, но это как с документацией в языках: раньше она была отдельно от кода, а теперь, благодаря LSP, когда я печатаю функцию, IDE показывает доку к ней прямо в подсказке, и это намного удобнее.