Simplifying Join Syntax
github.com
Simplifying Join Syntax
1–10 of 28 posts
Re: Simplifying Join Syntax
#2Cool idea! I always thought this was the purpose of cypher match statements but your syntax is much shorter and more familiar dot-pathing
One idea would be for the x.y.z to use functions like
x.y(argument).z
This way you could parameterize the traversals and it’d wind up looking like gremlin in sql
Re: Simplifying Join Syntax
#3Cool idea! I always thought this was the purpose of cypher match statements but your syntax is much shorter and more familiar dot-pathing One idea would be for the x.y.z to use functions like x.y(argument).z This way you could parameterize the traversals and it’d wind up looking like gremlin in sql
x.y(argument).z should be OK in syntax, but it is hard to implement. we can not predict which data type y(argument) would return, and if it can perform dot operation further.
We have implemented DQL(The syntax mentioned here) by translating to SQL. But we priovide only Chinese version now, we will release the English version serveral months later, please keep an eye out if you're interested
Re: Simplifying Join Syntax
#4There are many good ideas to improve SQL, though it is not easy to get traction as it is such an old standard with so many implementations
Re: Simplifying Join Syntax
#5“As all joins involve the primary key…”
Often but not always the case
Edit: at least not in SQL, and therefore SQL databases. If the language being described here isn't actually SQL, that could still be a problem.
Re: Simplifying Join Syntax
#6A 30 year old implementation of the same idea (even slightly better IMHO) can be found in kdb+/ksql/shakti, you can see examples and comparison in https://shakti.com/ (press document, then sql.d - no idea how to link directly). And yes, it is by Arthur Whitney and related to the [in]famous K
Re: Simplifying Join Syntax
#7More geniuses trying to "improve" SQL, and yet the only party to succeed in doing this is Postgres people, of actual relational SQL database—by means of dialect.
Re: Simplifying Join Syntax
#8I love the idea of a simplified SQL syntax for joins.
I have been working with graph databases for years now: these databases had to solve this problem from day one, because of the focus on relationships between entities.
I must point out that Neo4j was the first to propose a syntax that made traversal feel simple and natural again: the Cypher query language.
Neo4 and other industry players have spent years working on a new standard query language for graph databases that was released in April this year: GQL. GQL is the first database query language normalized by ISO since SQL, so it’s a big deal.
Anyway, if you wanna learn more about GQL, that a look at https://www.gqlstandards.org/
Re: Simplifying Join Syntax
#9This implicit JOIN feature is already present in HQL and also in Jooq. It's very convenient, especially when you use a star-like table structure where the important data table is basically just IDs and references.
https://www.jooq.org/doc/latest/manual/coming-from-jpa/from-...
Re: Simplifying Join Syntax
#10SOQL in Salesforce supports "relationship queries" that works on both directions, viz, parent-to-child and child-to-parent.
https://developer.salesforce.com/docs/atlas.en-us.soql_sosl....