Здесь под размером я имел ввиду количество строк (кортежей). Да, вы правы в том, что объем передаваемых данных будет больше (за счет повторяющихся колонок). Но это все речь идет об общении между бэкендом и БД, фронтэнду будет отдан уже преобразованный ответ в виде json (и вот он уже будет в точности таким же по объему).
Я конечно не знаю есть ли такие реализации в природе для реляционных СУБД, просто пытаюсь адекватно рассуждать. Но вот например для MongoDB HotChocolate умеет преобразовывать graphql-запросы в mongo-запросы 1-к-1.
Операция JOIN в SQL делается на основании условия, то есть это не все кортежи ко всем, это одновременно и объединение и фильтрация.
В Result Set в этом случае будут кортежи в которых частично повторяющиеся данные (это видимо и имелось ввиду под дублированием), но каждый из кортежей в итоге будет уникальным. Там могут складываться ситуации, когда дублирование действительно будет (зависит от схемы БД и запроса), но для этого можно просто DISTINCT к запросу добавить.
Выглядит как соломенное чучело.
И размер этого Result Set будет точно соответствовать сумме Result Set полученных в случае нескольких запросов. Просто представление другое, развернутое в реляционную модель. Другое дело что из ее немного сложнее сделать json с иерархией.
В этом случае, действительно, будет огромный результирующий набор из-за дублирования данных.
А можете раскрыть мысль, что тут имеется ввиду. Почему именно будет огромный набор? Что за дублирование данных? Ведь если мы делаем запрос к БД который вытаскивает ровно те поля, которые запрошены в GraphQL-запросе, то получаем ровно то что и нужно. То есть если сгенерировать SQL запрос 1-к-1 как GraphQL запрос, то это было максимально выгодно. Тогда и никаких DataLoader'ов будет не нужно. Вся сложность как раз в том, чтобы сгенерировать такой запрос.
Здесь под размером я имел ввиду количество строк (кортежей). Да, вы правы в том, что объем передаваемых данных будет больше (за счет повторяющихся колонок). Но это все речь идет об общении между бэкендом и БД, фронтэнду будет отдан уже преобразованный ответ в виде json (и вот он уже будет в точности таким же по объему).
Я конечно не знаю есть ли такие реализации в природе для реляционных СУБД, просто пытаюсь адекватно рассуждать. Но вот например для MongoDB HotChocolate умеет преобразовывать graphql-запросы в mongo-запросы 1-к-1.
Операция JOIN в SQL делается на основании условия, то есть это не все кортежи ко всем, это одновременно и объединение и фильтрация.
В Result Set в этом случае будут кортежи в которых частично повторяющиеся данные (это видимо и имелось ввиду под дублированием), но каждый из кортежей в итоге будет уникальным. Там могут складываться ситуации, когда дублирование действительно будет (зависит от схемы БД и запроса), но для этого можно просто DISTINCT к запросу добавить.
И размер этого Result Set будет точно соответствовать сумме Result Set полученных в случае нескольких запросов. Просто представление другое, развернутое в реляционную модель. Другое дело что из ее немного сложнее сделать json с иерархией.
А можете раскрыть мысль, что тут имеется ввиду. Почему именно будет огромный набор? Что за дублирование данных? Ведь если мы делаем запрос к БД который вытаскивает ровно те поля, которые запрошены в GraphQL-запросе, то получаем ровно то что и нужно. То есть если сгенерировать SQL запрос 1-к-1 как GraphQL запрос, то это было максимально выгодно. Тогда и никаких DataLoader'ов будет не нужно. Вся сложность как раз в том, чтобы сгенерировать такой запрос.