Re: Idea: Avoid JOINs by using path expressions to follow FKs

Поиск
Список
Период
Сортировка
От Vik Fearing
Тема Re: Idea: Avoid JOINs by using path expressions to follow FKs
Дата
Msg-id f2eff805-69ec-4968-788c-053abd32b168@postgresfriends.org
обсуждение исходный текст
Ответ на Idea: Avoid JOINs by using path expressions to follow FKs  ("Joel Jacobson" <joel@compiler.org>)
Ответы Re: Idea: Avoid JOINs by using path expressions to follow FKs  ("Joel Jacobson" <joel@compiler.org>)
Список pgsql-hackers
On 3/27/21 9:27 PM, Joel Jacobson wrote:
> Hi,
> 
> The database Neo4j has a language called "Cypher" where one of the key selling points is they "don’t need join
tables".
> 
> Here is an example from https://neo4j.com/developer/cypher/guide-sql-to-cypher/
> 
> SQL:
> 
> SELECT DISTINCT c.company_name
> FROM customers AS c
> JOIN orders AS o ON c.customer_id = o.customer_id
> JOIN order_details AS od ON o.order_id = od.order_id
> JOIN products AS p ON od.product_id = p.product_id
> WHERE p.product_name = 'Chocolade';
> 
> Neo4j's Cypher:
> 
> MATCH (p:product {product_name:"Chocolade"})<-[:PRODUCT]-(:order)<-[:PURCHASED]-(c:customer)
> RETURN distinct c.company_name;
> 
> Imagine if we could simply write the SQL query like this:
> 
> SELECT DISTINCT od.order_id.customer_id.company_name
> FROM order_details AS od
> WHERE od.product_id.product_name = 'Chocolade';
> 
> I took the inspiration for this syntax from SQL/JSON path expressions.

This is a terrible idea, but let me explain why.

First of all, neo4j claims they don't have joins because they actually
don't have joins.  The nodes point directly to the other nodes.  Your
proposal is syntactic sugar over a real join.  The equivalent to neo4j
would be somehow storing the foreign ctid in the column or something.

Secondly, and more importantly IMO, graph queries are coming to SQL.
They are mostly based on Cypher but not entirely because they amalgamate
concepts from other graph query languages like Oracle's PGQ.  The
"common" syntax is called GQL (https://www.gqlstandards.org/) and it's
in the process of becoming Part 16 of the SQL standard.  The timeline on
that website says August 2022 (it started in September 2019).

If that timeline holds and ambitious people work on it (I already know
one who is; not me), I would expect this to be in PostgreSQL 16 or 17.
The earliest your proposal could get in is 15, so it's not that much of
a wait.
-- 
Vik Fearing



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [Proposal] Global temporary tables
Следующее
От: "Joel Jacobson"
Дата:
Сообщение: Re: Idea: Avoid JOINs by using path expressions to follow FKs