6 ms·

Pretty much common knowledge... Doc db -> very cheap reads / very cheap writes Sgl db -> cheap reads / expensive writes Graph db -> cheap reads -> very expen

Pretty much common knowledge... Doc db -> very cheap reads / very cheap writes Sgl db -> cheap reads / expensive writes Graph db -> cheap reads -> very expensive writes ...for the type of data.

spinningslate 5y ago
If it were as simple as that, then surely the whole world would be using document DBs exclusively. The whole world isn't doing that. So maybe there's more to it. I'm doing some work right now where a graph is a good conceptual fit to the problem space. Writes are much less common than reads. A graph-theoretic approach is a good fit for the queries it needs to support; transitive closure and topological sort for example. Would I use a graph DB for a heavily transactional system like banking? No. Different problem, different requirements, different tech choice. But you seem to be suggesting that there are no problem scenarios where the characteristics of a graph DB are a good fit. That seems naive at best.
- AtNightWeCode 5y ago
  I am a senior IT architect. I give you the junior card but in the whole, you don't know at all what you are babbling about. ALL databases have tradeoffs.
  - spinningslate 5y ago
    Please refrain from personal attacks, it doesn't contribute to the discussion. And it's not consistent with the community guidelines [0]. > ALL databases have tradeoffs That was exactly my point. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - staticassertion 5y ago
    This is practically parody... I'm the founder of a company building a graph product. I've talked to numerous researchers in the field, read papers on the subject, I've even reviewed PHD candidates thesis for universities. I routinely field offers for consulting explicitly on graph database technology. You haven't said anything of substance and the little you have said has only served to convey your own ignorance on the subject. I've flagged a few of your posts since they break HN rules.
    - AtNightWeCode 5y ago
      I worked with graph databases. I also worked with graph like queries in SQL databases a lot for investigating money laundering, flow of payments between users and so on. In single systems that handles billions of Euros. This is easily done in SQL databases and has been since the eighties. In general the only reason to use a graph database as I wrote is when you want to trade expensive writes for cheap ad hoc graph queries. So if you are investigating international money laundering with a lot of different types of relationships between different types of entities and it is significant how the entities are related then SQL can be a poor fit. Or at least, you probably need to model a lot of the relationships as entities and keep on evolving the model with new data. With graph databases you could just enter all the data from different sources as nodes and edges and then perform any query on that data still with good performance. At least in theory. In practice it can be difficult to model graph databases too. The parody is that people suddenly thinks that there is a general need for graph databases.

Pretty much common knowledge... Doc db -> very cheap reads / very cheap writes Sgl db -> cheap reads / expensive writes Graph db -> cheap reads -> very expensive writes ...for the type of data.

spinningslate 5y ago

If it were as simple as that, then surely the whole world would be using document DBs exclusively. The whole world isn't doing that. So maybe there's more to it. I'm doing some work right now where a graph is a good conceptual fit to the problem space. Writes are much less common than reads. A graph-theoretic approach is a good fit for the queries it needs to support; transitive closure and topological sort for example. Would I use a graph DB for a heavily transactional system like banking? No. Different problem, different requirements, different tech choice. But you seem to be suggesting that there are no problem scenarios where the characteristics of a graph DB are a good fit. That seems naive at best.

AtNightWeCode 5y ago
I am a senior IT architect. I give you the junior card but in the whole, you don't know at all what you are babbling about. ALL databases have tradeoffs.
- spinningslate 5y ago
  Please refrain from personal attacks, it doesn't contribute to the discussion. And it's not consistent with the community guidelines [0]. > ALL databases have tradeoffs That was exactly my point. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- staticassertion 5y ago
  This is practically parody... I'm the founder of a company building a graph product. I've talked to numerous researchers in the field, read papers on the subject, I've even reviewed PHD candidates thesis for universities. I routinely field offers for consulting explicitly on graph database technology. You haven't said anything of substance and the little you have said has only served to convey your own ignorance on the subject. I've flagged a few of your posts since they break HN rules.
  - AtNightWeCode 5y ago
    I worked with graph databases. I also worked with graph like queries in SQL databases a lot for investigating money laundering, flow of payments between users and so on. In single systems that handles billions of Euros. This is easily done in SQL databases and has been since the eighties. In general the only reason to use a graph database as I wrote is when you want to trade expensive writes for cheap ad hoc graph queries. So if you are investigating international money laundering with a lot of different types of relationships between different types of entities and it is significant how the entities are related then SQL can be a poor fit. Or at least, you probably need to model a lot of the relationships as entities and keep on evolving the model with new data. With graph databases you could just enter all the data from different sources as nodes and edges and then perform any query on that data still with good performance. At least in theory. In practice it can be difficult to model graph databases too. The parody is that people suddenly thinks that there is a general need for graph databases.