Gerhard S.
"Neo4j Turns Historical Data into a Queryable Knowledge Graph"
What do you like best about Neo4j Graph Database?
What I like best about Neo4j is how naturally it models complex relationships, especially for an application like ours that stores interconnected data about arts, artists, places, countries and other entities. In a graph database, nodes represent entities (like artists or artworks) and relationships (like "created" or "exhibited") allow for a highly intuitive representation of how these elements connect.
This makes querying for complex patterns, like finding all artists who influenced a particular art movement or tracing the exhibitions of a certain artwork across different places, efficient and straightforward.
What are the main points that like it more about:
- That Neo4j optimizes queries for traversing relationships, such as "What art pieces were created by artists in a specific location?" which make the response faster than in traditional relational databases.
- We like that you can easily expand the graph with new relationships or attributes as your dataset grows.
- Also, we can search deeper in our data, finding more meaningful connections between our historical data, like trends in art styles or how artists influenced each other across regions, or the several relationship of multiple artist for a specific location or art
The flexibility and performance of graph-based queries really shine when dealing with highly relational data, like historical and cultural information. Review collected by and hosted on G2.com.
What do you dislike about Neo4j Graph Database?
While the Neo4j offers more positive advantages than disadvantages, but for our case specifically about our history app, there are a few challenges or limitations that might be points of concern, which can be improved:
- First big issue was about the restoring the old data from a different version of the database. Neo4j’s backup and restore processes are more complex compared to traditional relational databases. Maintaining backups for our history app can be a bit challenging, especially with the extensive and interconnected historical data which we are managing. As our dataset grows, ensuring that all this valuable information is securely backed up can require careful planning and additional effort.
- Different query language than traditional ones. Neo4j uses Cypher, which is different than traditional and may require time to learn especially if you're coming from a SQL background like I did. For more complex queries involving relationships between artists, artworks, places, and tags, Cypher syntax can become difficult to manage, especially as the graph structure grows more intricate, you need to optimize the query to not allow a lot of memory time in the whole process results
- Also, one more thing that we find of is importing data into Neo4j, especially from structured sources like Wiki pages, can be more complex than with traditional relational databases. The data needs to be transformed into a graph-friendly format, which can add a layer of complexity when dealing with large-scale imports or frequent updates from sources like Wiki. Review collected by and hosted on G2.com.
The reviewer uploaded a screenshot or submitted the review in-app verifying them as current user.
Validated through a business email account
Organic review. This review was written entirely without invitation or incentive from G2, a seller, or an affiliate.
