Когда не использовать neo4j?

Ответ 1

Возможно, вы захотите проверить эту слайд-панель и, в частности, слайды 18-22.

У вашего вопроса может быть много деталей, но позвольте мне попытаться сосредоточиться на больших кусках. Графические базы данных естественно индексируются по отношениям. Таким образом, базы данных графа будут хороши, когда вам нужно пройти много отношений. Графы сами по себе очень гибкие, поэтому они будут хороши, когда межсоединения между вашими данными должны время от времени меняться или когда данные о ваших основных объектах, которые важно хранить, должны быть изменены. Графики - очень естественный метод моделирования некоторых (но не всех) источников данных, таких как сети одноранговых сетей, дорожные карты, организационные структуры и т.д.

Графы, как правило, не умеют управлять огромными списками вещей. Например, если вы собираетесь создавать базу данных транзакций клиентов с помощью аналитики (там, где вам нужно 1 миллион клиентов, 50 миллионов транзакций и все, что вы делаете, это транзакции по почте в течение всего дня), то это, вероятно, не подходит. RDBMS отлично справляется с этим, обратите внимание, как этот вариант использования не использует отношения действительно.

Обязательно прочитайте эти две ссылки, которые я предоставил, они имеют гораздо больше обсуждений.

Ответ 2

По соображениям технического обслуживания любые сервисные агрегирующие фиды данных до сих пор были хорошо рекомендованы, чтобы их источники были независимыми.

Если я хочу исследовать отношения между различными каналами, это можно сделать на уровне приложения, используя отслеживание данных (например), предпочтения пользователя среди других каналов.

Графические базы данных касаются управления сложностью отношений, но эта сложность во многих случаях является выбором дизайна. Ввод всех ваших детей в одну ванну прекрасен, пока вы не уроните мыло.