News for hackers. Stuff that matters.
Re:New Query Language for Graph Databases to Become Internat... by u320 on Wednesday September 18, 2019 @12:13PM (#21006856)
> Some RDBs provide extensions to the SQL standard to do some basic graph traversals

This has been standardized since the SQL-1999 standard.

Re:New Query Language for Graph Databases to Become Internat... by twic on Wednesday September 18, 2019 @01:34PM (#21007791)
Are you referring to recursive common table expressions? These do allow graph queries. They are quite different to the proprietary extensions, though, and much more awkward.

I would love to see SQL grow a concise navigation/join syntax like JPQL's [1]; imagine writing:

  select e.name, e.department.head.assistant.name from employees
Instead of:

  select e.name, a.name
  from employees e,
  join departments d using (department_id)
  join employees h on d.head_id = h.employee_id
  join employees a on h.assistant_id = a.employee_id
Given that dots already mean something in SQL, maybe it would have to be:

  select e.name, e->department->head->assistant.name from employees
Once you've got that, it would not be a huge leap to add a recursive version of this operator.

[1] https://www.objectdb.com/java/jpa/query/jpql/path#Navigation...

Re:New Query Language for Graph Databases to Become Internat... by dragonwriter on Wednesday September 18, 2019 @01:58PM (#21008077)
> I would love to see SQL grow a concise navigation/join syntax

Yeah, what you need is a specification of a name to use for the referenced table in implicit joins when you sepcify an FK, then if you reference the linked table, it performs the join (to bring in a different subthread, such an implicit join specification could be the mechanism of opting-in for index-free adjacency on that FK, too, so you'd combine syntactic support with the supporting query optimization.)

Maybe something like:

  REFERENCES <table> [(<key columns>)] AS <link-name>
So, your example would be be supported by (assuming all the FKs are to PKs so you don't need columns specified on the FKs):

  FOREIGN KEY department_id REFERENCES departments AS department

  FOREIGN KEY head_id REFERENCES employees AS head

  FOREIGN KEY assistant_id REFERENCES employees AS assistant
...on the relevant tables.
Re:New Query Language for Graph Databases to Become Internat... by ken on Wednesday September 18, 2019 @01:42PM (#21007884)
Yet SQL still hasn’t standardized “CREATE INDEX” yet, has it? How many databases have implemented graph traversals, and do they even use the same syntax?

The various implementations of SQL are so different from each other, and from the spec, that I no longer find it useful to consider them the same language.

Is there a caniuse.com for SQL?

Re:New Query Language for Graph Databases to Become Internat... by dragonwriter on Wednesday September 18, 2019 @01:46PM (#21007935)
> How many databases have implemented graph traversals, and do they even use the same syntax?

Recursive CTEs with standard syntax are in virtually every current-versiom notable SQL-based RDBMS, including SQLite. I think MySQL 8.0 was the last of the major ones to add support.

Re:New Query Language for Graph Databases to Become Internat... by bcoates on Wednesday September 18, 2019 @02:40PM (#21008554)
CREATE INDEX is fundamentally an implementation detail of the RDBMS engine; there can be no meaningful standardization there.
Re:New Query Language for Graph Databases to Become Internat... by taffer on Wednesday September 18, 2019 @02:05PM (#21008181)
> Is there a caniuse.com for SQL?

Not exactly the same, but: https://modern-sql.com/