Да, будет. Хотя задача платформы максимально изолировать разработчика от работы с реляционной БД напрямую, тем не менее нельзя гарантировать, что во всех случаях мы сможем программно генерировать наиболее оптимальный код.
ER модель платформы скрывает от пользователя (разработчика) аспекты физической реализации структур данных. Чтобы пояснить разницу с традиционным подходом возьмем достаточно простой пример: выведем на печать компании из Могилевской области.
В Гедымине разработчик должен вручную прописать SQL запрос в функции отчета. В нашем примере для создания такого запроса необходимо знать что:
- Данные компании хранятся в трех таблицах, связанных между собой следующим образом:
GD_CONTACT JOIN GD_COMPANY LEFT JOIN GD_COMPANYCODE - Таблица
GD_CONTACTсодержит полеPLACEKEY, которое является ссылкой (FK) на таблицуGD_PLACE - В таблице
GD_PLACEесть полеNAME, по которому мы сможем найти объект Могилевская область. - Таблица
GD_PLACEимеет древовидную структуру - Для того, чтобы извлечь объекты произвольного уровня вложенности понадобится умение работать с рекурсивным CTE или со структурой интервальных деревьев платформы Гедымин.
И хотя здесь нет никакой "космической" науки, практически нереально, чтобы такой запрос смог написать среднестатистический специалист IT отдела заказчика или тем более рядовой бухгалтер.
В GDMN мы либо формулируем запрос на естественном языке:
"Покажи всех клиентов из Могилевской области",
либо создаем объект-запрос специальной структуры, который передаем системе для выполнения.
Для облегчения процесса, объект может быть создан с помощью графического построителя запросов.
И первое, и второе вполне по силам специалисту, разбирающемуся в своей предметной области, но не знакомому с тонкостями теории реляционных баз данных.
Нет. Данные сущности могут храниться где угодно: в реляционной базе данных, JSON файлах, CSV файлах и даже во внешних облачных источниках с доступом через REST или GraphQL.