За счет отказа от промежуточных таблиц для связей.
К примеру, Есть Топик, и у него есть свойство КемНаписан (Пользователь). В классической реляционной модели мы в таблице Топика просто добавляли колонку типа user_id, которая ссылалась на таблицу Пользователя через его id. Попутно могли настроить первичные/вторичные ключи, чтобы обеспечить целостность данных.
В итоге у нас было по прежнему две таблицы (Топики и Пользователи). В свою очередь через эту связь мы могли получить Пользователя по Топику, и по Пользователю
получить все его Топики.
В ранних версиях призмы эта связь обеспечивалась не через колонку в Топике, а через промежуточную таблицу ПользовательТопик. Таким образом связь выглядела так: Пользователь - ПользовательТопик - Топик.
Это обеспечивало все варианты связей (один-к-одному, один-ко-многим и многие-ко-многим). Но, это все-таки лишняя таблица, с кучей соответствующих минусов (включая усложнение написания SQL-запросов, в том числе и потому что колонки в таких таблицах имели "интуитивнопонятные" названия типа A и B).
Вот так вот этот ад выглядел: http://joxi.ru/brReEnMhYJ1VkA
А это только часть таких таблиц: http://joxi.ru/a2XWaY6ID1dZWm (имена таблиц связей начинаются с подчеркивания).
Сейчас подобных таблиц осталось всего 13 штук.
В принципе, на сами GraphQL-запросы это почти не повлияло (в плане их написания). То есть если мы раньше писали запрос
query {
users (
first: 3
){
id
username
Resources (
first: 3
){
id
name
}
}
}
то есть получали список пользователей и их публикации, то оно так и осталось. Просто под капотом на уровне самой призмы работа поменялась. Поэтому, если делать совсем не большой сервис, то это можно было и не брать во внимание. Но когда делаешь что-то побольше, да еще и начинаешь чистые SQL-запросы писать, то новая призма конечно же гораздо лучше себя показывает.