DEV Community

loading...

Discussion on: Building a Graph in SQL Land

Collapse
clun profile image
Cédrick Lunven

“After some research and exploration, it was decided that we'd avoid bringing in a true graph database (like Neo4j, OrientDB, etc.). Cost was potentially an issue, and we wanted to avoid forcing our developers to learn new concepts and a new query language”

=> Sorry but this decision is so stupid in many ways I cannot stay quiet...

  • graphDB is so obvious specially when you called your tables vertices and edges... no ?
  • cost, what cost most of those DB are free to use
  • you hire "engineer“ not amibo they should be able to learn ANY new query language in a week : specially gremlin or cypher so simple, way much simpler than the recursive SQL stuff

Anyway well written and thanks for sharing. Conclusion is gold : right tool for right use cases. Architects are like vampyrs they do not like silver bullets.

Collapse
annarankin profile image
Anna Rankin Author

Hi Cédrick - in hindsight, yes: it would have been worth it to use an actual graph database for this project. The cost wasn't the technology itself, but the cost of deployment, hosting, and instrumentation - and at the time, the PaaS we were using had less-than-stellar support for actual graph databases. The reasons we chose to implement the graph ourselves were flawed - and the whole reason I wanted to share :) Thanks!