> где наряду с NoSQL еще и графы используются
интересная формулировка)
> В каких случаях это в БД может быть полезно?
во всех задачах, где глубина и "разнообразие" связей между сущностями сравнимо с количеством этих сущностей.
Возьмем для примера две простые ситуации:
1) есть заказ в интернет-магазине с некоторым числом заказанных товаров. Вне зависимости от того, реляционную модель вы будете использовать или какую-то еще, скорее всего вам будет удобно рассматривать две сущности: Order и OrderItem. В первую вы добавите сведения обо всем заказе целиком (инф. о клиенте, дату заказа, выбранный способ доставки, способ оплаты и т.д.). Во второй сущности у вас будет, например, id товара и его количество (1 микроволновка, 2 флешки, 5 CD-R). Теперь, чтобы вы могли знать, что какие-то OrderItem имеют отношение к конкретному Order, вам следует тем или иным способом смоделировать связь. Если у вас SQL-база, вы добавите к Order-у поле Id, а к OrderItem поле OrderId и сделаете внешний ключ. Если у вас документная база, то, к примеру, можно весь заказ с его элементами разместить в одном json-документе, и элементы заказа будут подобъектами в массиве items объекта заказа. Со временем у вас появится много заказов и много элементов заказов. Однако связи между ними у вас всегда будут достаточно простые: у каждого заказа будет некоторое количество элементов. Сами заказы вы связывать не будете, как не будете связывать элементы заказа. Глубина связей сущностей будет ограничена одним переходом.
2) у вас есть социальная сеть (да, знаю, банальный пример), и конечно же у вас есть функция "добавить в друзья". В отличие от предудыщего примера, мы для рассмотрения можем взять только одну сущность - "пользователь", однако за счет того, что каждый каждого может зафрендить, у вас даже для одной сущности будет очень большой набор фактических связей, потенциально с большой глубиной (знакомые знакомых и т.д.).
Обе проблемы теоретически можно решить с помощью SQL баз данных, однако графовые базы будут выигрывать во второй задаче в сложных запросах по обработке связей (скажем, найти всех моих друзей, которые идут на такое-то мероприятие). Этот выигрыш вытекает из архитектурных особенностей графовой БД, например, в графовой базе часто при сохранении связи сохраняется "указатель" на физическое расположение связанных данных, в то время как в реляционной базе связи моделируются внешними ключами, и при обработке требуют выполнения операций поиска (пусть и индексированного). Вообще, в каком-то смысле связи в графовой БД это first-class citizens, а в реляционной БД связи моделируются программистом (ограничения целостности вроде внешних ключей просто помогают ему поддерживать данные в согласованном состоянии).
Средний
