3 ms·

Transaction isolation is a no-brainer, so I don't think your example holds. Also, your example is not related to the algebra but to isolation. "Claiming ACID"

by jexp 9y ago

Transaction isolation is a no-brainer, so I don't think your example holds. Also, your example is not related to the algebra but to isolation. "Claiming ACID" what is ambiguous about that? Transaction support with different serialization levels, like other databases that offer it. And Neo4j originally started b/c RDBMS was not able to execute the complex deep traversals needed in real time. Dedicated storage & query engine for graphs allow you to run statements quickly that would otherwise take too long to execute. Regarding the data model, the property-graph model is much closer to the object model but with richer relationships, it doesn't suffer from the object-rdbms impedance mismatch and is better suited to express real-world domains & scenarios. It also represents semantic relevant relationships as first class citizens in the database, allowing for proper information representation and much faster retrieval. Disclaimer: I work with/for Neo4j, for 8+ years and still love it.

v-yadli 9y ago
> "Claiming ACID" what is ambiguous about that? Transaction support with different serialization levels, like other databases that offer it. A non-graph-database would not provide operators like deep traversals. Operations are tightly bound to ACID as a whole, not just isolation. Of course ACID would always hold if you strictly linearize everything, but that defeats the purpose of data management, and one would achieve the same goal with even macro processors like `m4`. Getting traversals and other graph algorithms into the business means that there are lot of things that should be reconsidered, like constraints, and triggers. For example, if you cannot write a constraint to limit the local clustering coefficient of every entity, you do not proceed in your traversal with a good upper bound time budget. However, it is the vertices that you _don't_ visit that will propagate these constraints back while you are halfway there. Parallelizing such queries, in my opinion, is beyond state-of-the-art research.
- twic 9y ago
  > A non-graph-database would not provide operators like deep traversals You can do this with a recursive common table expression.
  - moxious 9y ago
    While this is technically true, in the SQL world this requires wizard level skills that most SQL developers do not possess, and when you arrive at this spot, you end up with a query that performs really, really badly. Look, between the database formalisms, they're all "complete" in the sense that you can choose any database and solve all the problems. But certain databases are going to be pathologically bad at solving certain types of problems, which is why there are so many sub-niches that persist over time. For deep path traversals, you can do it with RDBMS, but a graph DB is going to win every time in part because the data structure is just set up for that purpose. There are other queries where RDBMS will be best too. So it goes.
  - branko_d 9y ago
    Recursive CTEs are breadth-first, which may not always be what you need.

by jexp 9y ago

v-yadli 9y ago

> "Claiming ACID" what is ambiguous about that? Transaction support with different serialization levels, like other databases that offer it. A non-graph-database would not provide operators like deep traversals. Operations are tightly bound to ACID as a whole, not just isolation. Of course ACID would always hold if you strictly linearize everything, but that defeats the purpose of data management, and one would achieve the same goal with even macro processors like `m4`. Getting traversals and other graph algorithms into the business means that there are lot of things that should be reconsidered, like constraints, and triggers. For example, if you cannot write a constraint to limit the local clustering coefficient of every entity, you do not proceed in your traversal with a good upper bound time budget. However, it is the vertices that you _don't_ visit that will propagate these constraints back while you are halfway there. Parallelizing such queries, in my opinion, is beyond state-of-the-art research.

twic 9y ago
> A non-graph-database would not provide operators like deep traversals You can do this with a recursive common table expression.
- moxious 9y ago
  While this is technically true, in the SQL world this requires wizard level skills that most SQL developers do not possess, and when you arrive at this spot, you end up with a query that performs really, really badly. Look, between the database formalisms, they're all "complete" in the sense that you can choose any database and solve all the problems. But certain databases are going to be pathologically bad at solving certain types of problems, which is why there are so many sub-niches that persist over time. For deep path traversals, you can do it with RDBMS, but a graph DB is going to win every time in part because the data structure is just set up for that purpose. There are other queries where RDBMS will be best too. So it goes.
- branko_d 9y ago
  Recursive CTEs are breadth-first, which may not always be what you need.