Czy dobrym pomysłem jest używanie MySQL i Neo4j razem?

Relacyjne bazy danych mogą obsługiwać struktury grafów. Niektóre z nich mogą nawet obsługiwać je umiarkowanie elegancko (tak elegancko, jak robi się to w relacyjnej bazie danych!).

Kluczem do ogólnej obsługi grafów w relacyjnych bazach danych jest recursive common table expression (rcte), które zasadniczo pozwala iteracyjnie (nie rekurencyjnie, pomimo nazwy) rozszerzać Zapytanie o zestaw wierszy, łącząc zapytanie, które wybiera główny zestaw wierszy i zapytanie, które definiuje sąsiadów wierszy wybrane do tej pory. Składnia jest trochę niezgrabna, ale jest ogólna i potężna.

RCT są obsługiwane w PostgreSQL, Firebird, SQL Server i najwyraźniej w DB2. Oracle ma inną, ale równoważną konstrukcję; czytałem, że najnowsze wersje obsługują odpowiednie RCT. MySQL nie obsługuje RCTEs. Jeśli nie jesteś przywiązany do MySQL, zachęcam cię do rozważenia korzystania z PostgreSQL, który jest w zasadzie dużo lepszą bazą danych.

Jednak wygląda na to, że nie musisz wspierać ogólne wykresy, tylko drzewa. W takim przypadku dostępne są bardziej szczegółowe opcje.

Jeden z nich to klasyczne, ale raczej zaklinające umysł zestawy zagnieżdżone.

Prostszym jest przechowywanie ścieżki z każdym wierszem: jest to ciąg znaków, który reprezentuje pozycję wiersza w drzewie i ma właściwość, że ścieżka dla węzła jest prefiksem ścieżki dla dowolnego podnodu, co pozwala bardzo efektywnie wykonywać różne zapytania dotyczące przodka ("is node A A child of node B?", "co to jest węzeł A i najniższy wspólny przodek węzła B?", itp.). Na przykład można zbudować ścieżkę dla wiersza, przechodząc drzewo od korzenia i łącząc identyfikatory wierszy napotkanych po drodze z ukośnikami. Jest to proste do skonstruowania, ale dba o utrzymanie, jeśli zmienisz układ drzewa. W kolumnie path możesz ograniczyć zapytanie do danego drzewa po prostu dodając and path like '23/%', gdzie 23 jest identyfikatorem korzenia.

Tak więc, chociaż baza danych Wykresów jest prawdopodobnie najlepszym sposobem na przechowywanie i odpytywanie danych Wykresów, to nie jest jedyną opcją i sugerowałbym rozważenie zalet korzystania z jednego z zalet posiadania wszystkich danych w jednej bazie danych.

Jestem głównie z Binary Nerd w tym, ale chciałbym dodać odmianę. Możesz przechowywać dane na żywo w Neo4j, a następnie wyodrębnić dane potrzebne do statystyk/raportowania i umieścić w MySQL. Dla wyszukiwań wybrałbym integrację Neo4j-Lucene jeśli pasuje do Twoich potrzeb.

Możesz poprawić zapytanie używając IN:

SELECT *
FROM items
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345)