4 ms·
I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TA
by quickthrower2 6y ago
I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.
- dragonwriter 6y ago> If SQL is based on tables, what about a QL based on relations only. Aside from DDL (which I'm not sure how you would do without distinguishing between base relvars [tables], derived relvars [views], and other classes of relations), SQL doesn't particularly treat different kinds of relation differently beyond what is minimally necessary (you can't write, via insert or update, to a relation that isn't a relvar, for instance.)
- deleted 6y ago[deleted]
- iddan 6y agoThis is what we are trying to do with Cayley https://github.com/cayleygraph/cayley https://github.com/cayleygraph/cayley
- woile 6y agoThe website needs a link to the documentation, I just couldn't find it :/
- p4bl0 6y agoAre you thinking of Datalog?
- rplst8 6y ago> If SQL is based on tables, what about a QL based on relations only. Try Sparql.
- udp 6y agoCame looking for the reference, and found it - but there are fewer and fewer mentions of SPARQL with each of these HN discussions. I think people just think "oh some semantic web crap" and move on without realising how powerful RDF etc. really can be when used as simple tools, without the 90s hype of changing the world with linked data. At least the old ideas are resurging in the form of Neo4j (essentially a triplestore) and Cypher (essentially SPARQL).
- tasubotadas 6y agoGremlin - https://en.wikipedia.org/wiki/Gremlin_(query_language) https://en.wikipedia.org/wiki/Gremlin_(query_language) Cypher - https://en.wikipedia.org/wiki/Cypher_(query_language) https://en.wikipedia.org/wiki/Cypher_(query_language)
- jeltz 6y agoIsnvt that true for SQL? SQL treats everything as a relation and does not make any difference between a table, a view, a set returning function, a sub query or a CTE.
- cmrdporcupine 6y agoI think you might be misunderstanding what a relation is in the relational algebra or relational db. It's not a relationship. A relation is nothing more than a set of sets. Tables are relations, and views are relations. The results of queries are also relations. This is a common misunderstanding of what the relational in "relational database" means. It's not (primarily) about relationships, except insofar that relationships can be described using relations and queried using relational algebra. But the key concept is that of the mathematical relation, as per Wikipedia: "In mathematics, an n-ary relation on n sets, is any subset of Cartesian product of the n sets (i.e., a collection of n-tuples)" So the goal of relational db languages is to provide tools for querying these sets of sets. Joins, Unions, Selections (Restrictions), and Projections are some of the tools that are provided. SQL provides some of these, though often calls them confusing names. For example, in SQL the "select" keyword begins the query statement, but selection proper (as per relational algebra, also called restriction) is actually what is expressed in the "where" clause. What comes after "select" in your query is technically "projection" (choosing which tuples/columns exist in the output). Many ORMs and similar tools get this messed up, because the authors of them know SQL, but not the relational algebra on which it is nominally based.