Is it a good idea to use MySQL and Neo4j together?

Question

I will make an application with a lot of similar items (millions), and I would like to store them in a MySQL database, because I would like to do a lot of statistics and sea

Answer 1

Relational databases can handle graph structures. Some of them can even handle them moderately elegantly (as elegantly as a relational database gets!).

The key to general graph handling in relational databases is the recursive common table expression (RCTE), which basically lets you iteratively (not recursively, despite the name) expand a query over a set of rows, by combining a query which selects a root set of rows and a query which defines the neighbours of rows selected so far. The syntax is a bit clunky, but it's general and powerful.

RCTEs are supported in PostgreSQL, Firebird, SQL Server, and apparently in DB2. Oracle has a different but equivalent construct; i have read that recent versions support proper RCTEs. MySQL does not support RCTEs. If you aren't wedded to MySQL, i would urge you to consider using PostgreSQL, which is basically a much better database all round.

However, it sounds like you don't need to support general graphs, just trees. In that case, there are more specific options open to you.

One is the classic but rather mindbending nested sets.

A simpler one is to store a path with each row: this is a string which represents the row's position in the tree, and has the property that the path for a node is a prefix of the path for any subnode, which lets you very efficiently do various queries about ancestry ("is node A a child of node B?", "what is node A and node B's lowest common ancestor?", etc). For example, you could construct a path for a row by walking the tree from the root, and joining the IDs of the rows encountered on the way with slashes. This is simple to construct, but does take care to maintain if you rearrange the tree. With a path column, you can restrict a query to a given tree simply by adding and path like '23/%', where 23 is the root's ID.

So, although a graph database is probably the best way to store and query graph data, it is not the only option, and i would suggest you weigh the advantages of using one against the advantages of having all your data in a single database.