Is Neo4j the right tech for helping me build a robot database?

Hello, I am a noob and I am in a dire need of advice concerning Neo4j, if it fits my project or not. It's easier to ask those who are experienced than read a whole book just to learn that you wasted your time with the wrong technology.

See, I am building this db about robots (I am talking about a website) and a robot is a part made of parts (+itself, as it is a part/object itself). It introduces recursion. A robot is made of a body (among other parts) that is made of a leg that is made of a thigh, etc. Each part has a set of tags (blue, metal), specifications (length), etc and the leg inherits the tags/specs of the thigh, the body inherits the tags/specs of the leg which inherited from the thigh, etc. A robot can have options, like a laser beam or a chainsaw. Same, with inherited tags/specs. Now, a part (ex: body) can have options that may or may not be inherited by the higher part (ex: the robot, because it's specialized). It can also add new parts (a new kind of breast plate) or tags/specs (an exclusive color), to the body used by the robot.

Hierarchies, recursivness, inheritance, they are not something that I can handle with a RDBMS like Mysql without major headache. The problem is that I want a powerful search engine that will be able to find every piece that has such and such tag or spec (ex: red led eyes, articulate feet, height between x and y), make that kind of complex queries with an unknown level of depth without god awful performances because of recursion.

Is Neo4j the way to go (integrated with procedural PHP), knowing that it's a major investment for a specific problem (and I really don't have time to learn something just to learn it doesn't solve my problem, I would honestly be in trouble as I have not extensive time :/).

Thank you for reading me.

In brief yes, I would utilize Neo4j for your project. You're essentially building a knowledge graph of parts that make up a robot. You'll see better performance as the level of recursion deepens and it'll be easier to identify shared components that robots have in common.

That's what I thought. Thank you for your answer.

Now, to make this thread useful, I have read the Getting Started Guide and some other stuff, and I have a question to kickstart me if you don't mind?

I said a part could have options that may or may not be inherited by a parent part that would select it (a body offers three breasts plates but one parent robot only uses one from the set). What is the best practice?

  • To not have a hierarchy and link a part to every part it is constituted with -[:HAS_SOMETHING {type:base|option}]->, optionally, three+ relationships :BASE, :OPTION, :HAS_SOMETHING (something=part_category). I still need the hierarchy to order the parts into a tree so even if it's faster, I will have to use recursion to check how the parts are nested. This option makes me feel like I am cluttering the DB with redundant relationships ((body)-[:HAS_BREASTPLATE:OPTION]->(breast_plate) + (robot)-[:HAS_BREASTPLATE:BASE]->(breast_plate) instead of just (robot)-[:HAS_BODY:BASE]->(body)-[:HAS_BREASTPLATE:OPTION]->(breast_plate)). It doesn't seem normalized at all if this principle still apply to neo4j. I will need to hierarchize my parts and so I will still need to check how the parts are related to each other.
  • To have a hierarchy with three+ relationships :BASE, :OPTION, :HAS_SOMETHING but use recursion for base parts and select directly options, with :OPTION. it looks more normalized but I will still need to check how the options are coming from as you jump over intermediates for every option.
  • ??? I don't know how you could link to the options while retaining the intermediates. I assume it makes no sense for the body to have a relationship related to its parent: (robot)-[:HAS_BODY:OPTION]->(body)-[:HAS_BREASTPLATE:BASE {parent:robot.id}]->(breast_plate). Every part at the bottom of a tree would have tons of relationships related to the top of the tree.

Also, is there some great resources with concrete examples as how to handle common web use cases such as tag cloud?