3 ms·

SQL is going to eventually die because of its three-pronged relationship model that implies query-time complexity. Learn it if you want, but especially backend

SQL is going to eventually die because of its three-pronged relationship model that implies query-time complexity. Learn it if you want, but especially backend and analytics people would be better off learning Gremlin or Cypher. Edit: downvoting this is not going to make it untrue.

Pamar 5y ago
For everyone (like, for example, me) who has never heard these two names before (or not as replacements for SQL at least...) maybe the following might be useful: https://stackoverflow.com/questions/13824962/neo4j-cypher-vs-gremlin-query-language https://stackoverflow.com/questions/13824962/neo4j-cypher-vs...
holoduke 5y ago
You are getting doenvoted because it's untrue. So many faang companies using traditional SQL. And for good reasons. Not to say your two examples are bad. They have their own benefit. But don't become the guy who believes in one replacement solution for all without the knowledge of all. It's annoying
- eurasiantiger 5y ago
  And how many FAANG companies are using a graph database?
helsinkiandrew 5y ago
That is a truism everything is eventually going to die - but SQL has been around for longer than just about all development technologies today and probably will be around a lot longer than things that are popular now. I would guess that it will be around when people have move on from React, Gremlin, and Cypher.
mr_toad 5y ago
For simple queries, row adjacency will beat the graph hands down. And RSBMSs are hard to beat for transactional processing.
- eurasiantiger 5y ago
  Plenty of graph databases, even distributed ones, come with transactional guarantees and ACID to boot. Not everything is eventual consistency.
anigbrowl 5y ago
Eventually is a long time. SQLite is committed to supporting its file format out to 2050 and it's the recommended format for data archival by the Library of Congress. I suspect SQL will still be going strong long after my final exit(). Thing is, it's pretty neat in many respects (simple enough to do simple things easily, surprisingly flexible), and I say that as someone who really likes graph databases.
hashhar 5y ago
You're getting downvoted most probably because your comment provides no arguments why. Why would I be better off with Gremlin or Cypher?
- eurasiantiger 5y ago
  Because it eliminates the complexity of joins: both the mind-complexity and the algorithmic complexity.
DemocracyFTW 5y ago
I for one am in theory very interested in graph DBs, but in practice I yet have to see how do implement a solutions for my particular set of data (and my ideas about the data) in a graph DB without it becoming a huge ball of spaghetti. If you're so enthusiastic about graph DBs that's good for you; as for me I enjoy having named rectangular sets of data (i.e. tables and views) consisting of smaller entities (columns / fields) that follow formally described rules (types, domains, check constraints, foreign keys and higher-order invariants). I do have a number of gripes about SQL but right now I feel quite happy about having achieved a reasonable way to integrate an RDBMS (SQLite) into my application environment (NodeJS) where I can fluently switch between formulating solutions in SQL or in JS with few restrictions. Programming means you have to constantly keep a number of balls in the air, all the time. Having my data in handy tables is a big boon and not something I currently can expect a graph DB to do for me.

Pamar 5y ago

For everyone (like, for example, me) who has never heard these two names before (or not as replacements for SQL at least...) maybe the following might be useful: https://stackoverflow.com/questions/13824962/neo4j-cypher-vs-gremlin-query-language https://stackoverflow.com/questions/13824962/neo4j-cypher-vs...

holoduke 5y ago

You are getting doenvoted because it's untrue. So many faang companies using traditional SQL. And for good reasons. Not to say your two examples are bad. They have their own benefit. But don't become the guy who believes in one replacement solution for all without the knowledge of all. It's annoying

eurasiantiger 5y ago
And how many FAANG companies are using a graph database?

helsinkiandrew 5y ago

That is a truism everything is eventually going to die - but SQL has been around for longer than just about all development technologies today and probably will be around a lot longer than things that are popular now. I would guess that it will be around when people have move on from React, Gremlin, and Cypher.

mr_toad 5y ago

For simple queries, row adjacency will beat the graph hands down. And RSBMSs are hard to beat for transactional processing.

eurasiantiger 5y ago
Plenty of graph databases, even distributed ones, come with transactional guarantees and ACID to boot. Not everything is eventual consistency.

anigbrowl 5y ago

Eventually is a long time. SQLite is committed to supporting its file format out to 2050 and it's the recommended format for data archival by the Library of Congress. I suspect SQL will still be going strong long after my final exit(). Thing is, it's pretty neat in many respects (simple enough to do simple things easily, surprisingly flexible), and I say that as someone who really likes graph databases.

hashhar 5y ago

You're getting downvoted most probably because your comment provides no arguments why. Why would I be better off with Gremlin or Cypher?

eurasiantiger 5y ago
Because it eliminates the complexity of joins: both the mind-complexity and the algorithmic complexity.

DemocracyFTW 5y ago

I for one am in theory very interested in graph DBs, but in practice I yet have to see how do implement a solutions for my particular set of data (and my ideas about the data) in a graph DB without it becoming a huge ball of spaghetti. If you're so enthusiastic about graph DBs that's good for you; as for me I enjoy having named rectangular sets of data (i.e. tables and views) consisting of smaller entities (columns / fields) that follow formally described rules (types, domains, check constraints, foreign keys and higher-order invariants). I do have a number of gripes about SQL but right now I feel quite happy about having achieved a reasonable way to integrate an RDBMS (SQLite) into my application environment (NodeJS) where I can fluently switch between formulating solutions in SQL or in JS with few restrictions. Programming means you have to constantly keep a number of balls in the air, all the time. Having my data in handy tables is a big boon and not something I currently can expect a graph DB to do for me.