Добрый день! Увидел в FAQ одной из статей Уроков, что планировался функционал Visual SQL Designer. Будет ли его реализация?
Не раньше второго квартала 2025 года. Мы начинали его делать, но постепенно его актуальность упала по отзывам текущих пользователей. SQL Exec мощнее и работает лучше.
Понятно, спасибо. SQL Exec - это наверное больше для профессионалов, которые хорошо разбираются в коде. А для обычных пользователей, думаю визуальный конструктор запросов был бы кстати. Опять-таки, прошу прощения, что с Bubble сравниваю, но там все просто на интуитивном уровне - просто выбираешь логические параметры, в целом ничего лишнего не выберешь, и “мастеришь” выборку данных любой сложности. Визуализация все равно дает больше понятия что ты делаешь, что за “поля” берешь, какие фильтры и условия применяешь на “человеческом” языке. Было бы неплохо, конечно, делать запросы на таком конструкторе, и чтобы был в итоге виден “код” запроса, который потом более профессиональные пользователи уже могли бы дорабатывать для себя, например, при помощи того же SQL Exec.
Кстати, не нашел в документации что такое SQL Exec и как с ним работать. Есть где посмотреть, может примеры, видео?
Для новичков предусмотрены автогенерируемые блоки DB: Search/GetOne/Create/Update/Delete. Они автоматически создаются платформой для каждой модели, позволяют достаточно просто манипулировать данными в БД без написания какого-либо кода и поддерживают сложные запросы с вытаскиванием данных из связанных таблиц (параметр _with). Если нужно делать кастомные запросы - только писать чистый SQL и выполнять его блоком SQL Exec напрямую в БД.
SQL Exec это просто блок, выполняющий ваш SQL код и выдающий в ответ JSON форматированные данные из СУБД. Мы используем PostgreSQL, соответственно синтаксис должен быть ее же. Если вы делаете обычный проект, то стандартных блоков должно хватить - нет смысла писать SQL.
В том и дело, что у меня не обычный проект… Предполагается вытаскивать данные нескольких “уровней” связанности на одной странице. Если уже очень примитивно, то “Дед-Отец-Сын” (если так можно выразить цепочку связей). Т.е. например, есть условная модель данных: Заказчик со связью один-ко-многим к Заказы. И соответственно, Заказы со связью один-ко-многим к Товары.
Дерево структуры такое:
- Заказчики
-
- Заказы
-
-
- Товары
-
И если я строю визуальный интерфейс, то мне нужно вывести на странице Заказчика таблицу (или кастомно настроенный список) подчиненных Заказов, в которой (в каждой ячейке, получается) будет список/таблица подчиненных Товаров.
Грубо говоря на странице Заказчика таблица Товаров в таблице Заказов - как бы “запрос с подзапросом”.
Такое можно реализовать имеющимися инструментами блоков, или нужно строить какой-то кастомный код?
Если вы только начинаете знакомится с базами данных, то лучше это все делать существующими блоками, а не через SQL. Он хоть и дает больше возможностей, но требует больше знаний и понимания как это работает.
То что Вы описали без проблем можно сделать существующими инструментами, просто это будет не один запрос, а несколько в пределах одного БП. Вообще можно собрать модель данных любой вложенности.
Но на интерфейсе лучше всего, если вы будете подгружать данные частями - т.е. открыли список заказчиков, перешли в заказчика, показали список заказов, перешли в заказ, показали список товаров.
А еще мне кажется Вы один уровень вложенности пропустили 
Заказчики - Заказы - Строки заказа - Товары
Это не моя прихоть)) Это требование моего клиента, для которого планируется разработка веб-портала)). Но если такая сложная конструкция реализуется встроенными пользовательскими инструментами - это супер!
Возможно и так, я просто со своей колокольни объясняю, еще не знаком как тут строится многоуровневая структура подчинения (связей). Я так понимаю, тут можно выстроить только Родительско-дочернюю связь. Какой-то автоматической связи по цепочке не создается? Т.е. в моем примере Товар не будет “знать” своего Заказчика, а только свой Заказ. И для этого и нужно строить запрос с подзапросом? Просто в некоторых других платформах по умолчанию есть наследственность, если выстраивается многоуровневая структура подчинения (т.е. отслеживается цепочка связей сразу, там какой-то уже встроенный запрос, который видит все связи по структуре). Надеюсь все понятно выразил))
В бизнес процессах, Вы можете сделать запрос на один уровень вложенности, но в количестве запросов Вы не ограничены. Т.е. можете выбрать сначала всех заказчиков и их заказы, потом пройтись в цикле по каждому заказу и получить строки заказа с товарами и на выходе собрать все вместе в одну модель с вложенными заказами, строками и товарами.
Связь по цепочке создается какая угодно.
Т.е. если вам нужно найти все товары которые заказывал заказчик “А”, то все тоже самое, что я выше описал делаете и на выходе формируете ту структуру которая нужна. Если нужно, то можно просто списком отдать все товары или отдать в виде иерархии заказчик-заказ-строка-товар.
1 Like
Спасибо за разъяснения, буду уже на практике пробовать) Если что замучаю вас вопросами))
1 Like