Comments 4
Исходя из того, что DAX - язык аналитических запросов, то прикручивать его было бы логичней к CH, а не к PostgreSQL.
Вопрос же о весьма сомнительных преимуществах DAX перед SQL оставим за скобками.
прикручивать его было бы логичней к CH, а не к PostgreSQL
Да, это и имплементировано, например, в Visiology и DAX Visiology работает в ClickHouse.
В этой статье PostgreSQL взята в качестве примера СУБД, можно взять любую другую.
Вопрос же о весьма сомнительных преимуществах DAX перед SQL оставим за скобками
Такое впечатление, что описанный подход полезен при любом отношении к DAX в сравнении с SQL:
если DAX "нравится", то расширяются возможности его применения;
если DAX по каким-то причинам "не нравится", то рассматривается получение SQL, соответствующего DAX.
Да, это и имплементировано, например, в Visiology и DAX Visiology работает в ClickHouse.
За эту информацию спасибо!
при любом отношении к DAX в сравнении с SQL
Вопрос не в нравится или не нравится. Вопрос в том, что для того, чтобы достаточно сложные конструкции DAX перевести на PostgreSQL, потребуются значительные усилия в целях оптимизации результирующего запроса. И если пользователь SQL может ознакомиться с планом запроса и сделать соответствующие выводы, то пользователь DAX будет не понимать, почему его запрос не может часами выполниться. И никакой понятной ему информации предоставить будет невозможно.
Выполнение DAX запроса AI DAX движка в СУБД на примере PostgreSQL