3 ms·
Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. Sure you can represent a GraphDB in a RDB
by voodooEntity 2y ago
Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky.
Sure you can represent a GraphDB in a RDBMS - but graphdbs are optimized for their specific use case. Therefor for example locking of resources is optimized for said purpose. When going a "Edge" and "Node" table approach, locking is by default rather unoptimized in many RDBMS. Just one simple example.
- SJC_Hacker 2y ago> Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. If your text processing stack works good enough, and JSON only solves edge cases, then I think its a legit argument against adding another tech to the stack. Its not like everyone immediately switched over to JSON even if they could have. And the analogy may not be the best - in the case of graph databases, they don't do what RDBMS can do, at least not as efficiently. So if we need some graph functionality in our RDBMS, do we split the database and use a "real" graph database or just incorporate the graph functionality into the existing DB? The choice seems quite easy for me, because there are whole host of issues in splitting DBs (duplication of information, inconsistency, etc.)
- voodooEntity 2y agoWell i took the best example that came to my mind at that moment. may not be the best analogy but well its what it is. My point was not about people enrichhing an existing RDMBS concept with Graph, it was about using RDBMS as Graph (as only purpose). So maybe i wasn't exact enaugh in my definition. Therefor: "If your purpose is to use the benefits of Graph and you want to use it for this purpose only, use a GraphDB and dont use a RDBMS and make it a GraphDB." I hope thats better now.