Comments 7
И придумал бог ORM и стало всем хорошо.
Так и не понял смысл нового #языка# начнем по пунктам
1 уничтожение комментариев
2 игнорирование СУБД
Да вы можете любить питон и ещё что либо
Но почему вы игнорируете процедурный язык самой СУБД?
Про хинты и прочие оптимизации вы слышали?
игнорирование СУБД: так как мой язык компилируется в SQL, то есть в БД летит один SQL-запрос. Это как раз принципиальный момент: я хочу создать компактный и удобный для человека язык, который при этом будет быстрым, так как будет компилироваться в SQL и выполняться как SQL.
Насчёт оптимизации — это сложный вопрос. Я уверен, что запросы, где очень важна оптимальность и которые выполняются часто и много, безусловно останутся на чистом SQL с хинтами, и автоматически я не смогу делать лучше. Но целевой областью своего языка я вижу именно аналитические запросы, которые часто выполняются всего один раз или очень редко (посмотрел интересующий меня срез, ничего интересного не увидел — пошёл дальше), и в такой парадигме, если я пишу запросы, которые будут выполняться раз в неделю, месяц или вообще один раз, но мне нужно написать их 100 разных, очень важна именно выразительность языка, а не его оптимальность.
При этом, например, переиспользуемость метрик важна, чтобы был один источник истины: доход с продаж мы считаем везде одинаково (не с точки зрения скорости и оптимальности).
уничтожение комментариев: наверное, вы про
@link(pets, machines)и т. д. Это спорный момент. В свою защиту могу сказать, что таких тагов немного — не больше одного на столбец — и это не сильно мешает читать остаток коммента (на мой взгляд). Более того, часть тагов (link,id) можно добавить в виде primary/foreign key, оставшиеся можно и не указывать — просто качество модели данных станет чуть хуже. Также можно добавить возможность подгружать эту инфу отдельным файлом YAML.
Вообще спасибо большое за вопросы.
Проблема в том что комментарии нужны не только вам а к примеру также аналитику из соседнего отдела с негоо другой аналитической модель . Разработчику
По поводу скорости работы. Крайне зависит от объема данных и сложности выборки. Даже вас я думаю не устроит выборка формируемая в течение 50+ часов.
.
про коментарии тогда второй подход создать для того кто пользуется моей системой отдельную схему с вьюшками на изначальные таблицы и в этих виюшках уже будут коменты. всё равно в реальности обычно для построения ветрин данных используются инструменты типа dbt, sqlmesh и нету проблемму для каждого отделу создать свою вьюшку, для этого кст и нужен таг link тк очень часто исходники это не физические таблички а вьюшки а к ним в описание primary/foreign key уже не добавишь (зависит от бд).
Даже вас я думаю не устроит выборка формируемая в течение 50+ часов.
безусловно запрос который работает больше 5 минут уже плохо нужно думать как оптимизировать. Но тут скорее это какоето предогрегирование добавление копии таблицы с другой сортировкой если мы говорим про кликхаус. для этого используют dbt, sqlmesh. безусловно для таких вещей мой язык не подходит
Жесть. SQL самый простой и ужасный язык. За 30 лет он слабо изменился. Но все время его хотят улучшить. Так придумали orm. Теперь надо знать orm и sql. Некоторые стали считать, что sql, не надо знать. Ребята выучитье sql и не придется ничего изобретать.
TypeQL: SQL для аналитиков, который знает о данных всё