3 ms·

Thanks! Hmm, why aren't graph queries useful for CRUD? I don't get it. C — create a new node (possibly with some edges). R — get one or a list of nodes fitti

Thanks! Hmm, why aren't graph queries useful for CRUD? I don't get it. C — create a new node (possibly with some edges). R — get one or a list of nodes fitting some criteria (including being connected to other nodes). U — update a given node and possible its edges, and also possible some adjacent nodes. D — drop the node and its edges. Which of these is conceptually more difficult with graph DBs?

ajkjk 5y ago
All of them? It's a lot more to think about than in a relational DB where you only have to reckon with a 'node', not any of its connections. (or, if you have some tables related by key, just processing everything under that key.)
jodrellblank 5y ago
I assume "CRUD" here means "boring business use" such as "customers and their order history" or "customers who brought a car in for servicing" or "customers and their cable TV subscriptions". The customers aren't connected to each other in any social/graph way, the database just stores them as a list while employees CRUD one customer's details at a time. What benefit from a graph DB there?
- beardyw 5y ago
  CRUD = create, read, update, delete
  - jodrellblank 5y ago
    Yes, that's what Kirilrogovoy said that I was replying to. Yo can can do those things in a graph database, so I'm speculating that the original commentor didn't mean "CRUD" as literally "create read update delete" but in the sense of "most uses of databases are unexciting". Crud doubles as a lightly rude word, covering low-end drudge work. "another cruddy web database today, I'm sick of this". When someone needs to store today's office visitors, they don't need to know who shared the visitor log on Facebook and how many people liked it, or how many visitors removed from Kevin Bacon they all are, it just needs a list with a bit more structure than CSV, and that kind of use dominates what people do with databases.
    - beardyw 5y ago
      Sorry, just thought I was being helpful.
    - salawat 5y ago
      Let me ask my first architect's favorite question: What does <a graph database> add that I can't get out <the relational one> I already use, and does <that thing> matter in the context I'm building in enough to justify the cost of migration/maintenance? In a surprising number of contexts, the answer is nothing, in which case you stop, or something, and no, which is also a stop. The Architect's point of view should take into account the relative availability of talent and cost of materials to get the job done. This is part of what makes them the Aspirant Developer's mortal enemy. This way of formulating a question though, despite it's frustrating effectiveness at short-circuiting new-shiny for new-shiny sake, also excells for getting juniors on the road to becoming technical experts.
tlarkworthy 5y ago
the delta between a graph DB and a relational DB is graph can formulate queries such as X is connected to Y, and stuff that is some kind of walk over the graph. None of that is relevant for CRUD apps. Releational can model a graph but can only answer queries like X is an immediate neighbour of Y. It lacks the walks (SQL recursive is kinda there but not really). The primary purpose of a DB is to serve queries. But graph DB's queries are not so useful for most "lookup" type workloads that dominate business. So a graph DB is overkill, and when you get into the nitty gritty, cannot do many performance optimizations as a result. So a graph DB is a worse relational DB. But immediate relations are what is interesting to business.

ajkjk 5y ago

All of them? It's a lot more to think about than in a relational DB where you only have to reckon with a 'node', not any of its connections. (or, if you have some tables related by key, just processing everything under that key.)

jodrellblank 5y ago

I assume "CRUD" here means "boring business use" such as "customers and their order history" or "customers who brought a car in for servicing" or "customers and their cable TV subscriptions". The customers aren't connected to each other in any social/graph way, the database just stores them as a list while employees CRUD one customer's details at a time. What benefit from a graph DB there?

beardyw 5y ago
CRUD = create, read, update, delete
- jodrellblank 5y ago
  Yes, that's what Kirilrogovoy said that I was replying to. Yo can can do those things in a graph database, so I'm speculating that the original commentor didn't mean "CRUD" as literally "create read update delete" but in the sense of "most uses of databases are unexciting". Crud doubles as a lightly rude word, covering low-end drudge work. "another cruddy web database today, I'm sick of this". When someone needs to store today's office visitors, they don't need to know who shared the visitor log on Facebook and how many people liked it, or how many visitors removed from Kevin Bacon they all are, it just needs a list with a bit more structure than CSV, and that kind of use dominates what people do with databases.
  - beardyw 5y ago
    Sorry, just thought I was being helpful.
  - salawat 5y ago
    Let me ask my first architect's favorite question: What does <a graph database> add that I can't get out <the relational one> I already use, and does <that thing> matter in the context I'm building in enough to justify the cost of migration/maintenance? In a surprising number of contexts, the answer is nothing, in which case you stop, or something, and no, which is also a stop. The Architect's point of view should take into account the relative availability of talent and cost of materials to get the job done. This is part of what makes them the Aspirant Developer's mortal enemy. This way of formulating a question though, despite it's frustrating effectiveness at short-circuiting new-shiny for new-shiny sake, also excells for getting juniors on the road to becoming technical experts.

tlarkworthy 5y ago

the delta between a graph DB and a relational DB is graph can formulate queries such as X is connected to Y, and stuff that is some kind of walk over the graph. None of that is relevant for CRUD apps. Releational can model a graph but can only answer queries like X is an immediate neighbour of Y. It lacks the walks (SQL recursive is kinda there but not really). The primary purpose of a DB is to serve queries. But graph DB's queries are not so useful for most "lookup" type workloads that dominate business. So a graph DB is overkill, and when you get into the nitty gritty, cannot do many performance optimizations as a result. So a graph DB is a worse relational DB. But immediate relations are what is interesting to business.