1. 60
  1.  

  2. 26

    If this sort of thing interests you, you’ll enjoy reading *Databases, Types, and the Relational Model: The Third Manifesto.

    The authors, who are legends in the field, rigorously define a type-safe (and NULL-safe) data model and query language based on the relational algebra. It’s truly beautiful, and it’s one of the best-written computer science books I’ve ever read (and I’ve read a lot).

    I even have a dead-tree copy of the book. It’s huge. It has to sit sideways on my shelf.

    1. 1

      Thanks

    2. 7

      The fact that there isn’t some sort of postgreSQL extension providing a low-level “just provide a query plan” syntax despite database weenies being all about “performance” and “controlling the machine” is one of the things that confuse me the most.

      This thing seems to be proposing a new DB along with a new syntax, but you really don’t need a new DB for standard cases. Postgres is pretty good, and the internals make a lot of sense when dug into! Just give a nicer interface to it.

      1. 5

        EdgeDB is built on top of PostgreSQL is it not? I really have no experience with it, but that’s what it says on their front page.

        1. 3

          I totally agree on this.

          I was wondering a while ago whether it would be possible to build some better syntax (than SQL) around Postgres’ wire format.

          I was extremely appalled when I saw that they were sending SQL strings over the wire.

          Isn’t there some internal format that can be exposed that allows a saner way to build queries?

          1. 4

            What’s wrong with sending SQL over the wire? Do you instead propose clients should implement a SQL parser? Why?

            1. 2

              Tagging on to this — the fastest way to replace SQL would be a language like this that could target PostgreSQL, SQL Server, MySQL, etc. Having a single cross DB language could be enough of a draw on its own.

              1. 2

                I’m working on one right now! It looks like Javascript met GraphQL, but compiles to SQL.

              2. 2

                Because that SQL needs to be built somehow, and programmatically generating SQL queries is a huge PITA.

                Just give me some sane binary format to target instead that composes cleanly and received any kind of design thought at all.

                1. 1

                  I think it is a trend, i.e., moving parser to client runtime or even to the client application compile / deployment time (i.e., postgreSQL’s connection becomes an implementation detail while for each language has an official binding that does the parsing + query representation generation).

                  Personally, I think there is a reason why the other way succeed (postgreSQL, or to an extreme, redis like simple ASCII protocol). Making official binding for each language can become unwieldy unless you are Google (to maintain protobuf).

                  1. 2

                    The difficulty in tools like PostgreSQL is that they need to do more than just parse the query; the query planner also analyses it and uses information from the database in order to effectively run it. Redis, by comparison, is dead simple.

                    Essentially, you’re sending programs to a server to be run. Perhaps there is a slightly better way to do this than plain-text SQL, but I’m not so sure the advantages would be that great.

                    1. 1

                      I don’t think query planning is doable from client-side? You need to know full schema and (maybe) some data distributions to do that efficiently.

                      1. 1

                        Yeah, that was my point haha. I think I may have misunderstood the last paragraph of your previous comment the first time I read it 😅

              3. 2

                I’ve wondered what you could do with some RDBMS with a VM as the interface. With some language creation tooling people could really explore the design space.

                I know that SQLite uses a VM internally. I wonder if it would be possible to expose it.

              4. 4

                If you want to look at some other interesting alternative query models, Datalog is worth looking into.

                1. 4

                  It is funny to see an article about writing better SQL mentioning both Codd and PostgreSQL without mentioning QUEL even once. Not only it was query language designed by Codd himself, it was also the first query language in Postgres (then it was named PostQUEL). And IMHO QUEL is clearer than proposed EdgeQL.

                  1. 3

                    I have a manual of Ingres QUEL on my desk (from the times that Ingres shipped with both SQL and QUEL). I remember my supervisor (who had worked on initial (Stonebraker’s) Postgres) saying that QUEL was superior, but in the end this did not matter. SQL marketing won.

                    1. 1

                      Maybe it is time for the great come back of QUEL. With current state of query languages it do not matter that much anymore to follow “the marketing”.

                      1. 2

                        I wouldn’t mind working on a QUEL implementation for anything, but I’d need someone to pay me for it :) Unfortunately we do not always get paid for the next cool thing that can be reintroduced in CS :(

                  2. 4

                    This looks interesting. Much better than I expected (looks like an upgrade over GraphQL). After reading some docs I am still confused about how EdgeQL handles missing data. Assuming User.name is empty while User.id exists. What result I am getting for:

                    SELECT User {
                      name,
                      id
                    }
                    

                    ?

                    There is an example of boolean logic over empty set, I find it is a bit confusing as well: SELECT True OR <bool>{} returns <bool>{}.

                    I guess my confusion comes from the fact that “everything is a set”, while there are structures (schema) for data query results (can be a set of “objects”). Because “set” is also flat, how do we handle missing data from objects? (Otherwise the boolean logic case can go unchallenged, after all, query by boolean against a set of booleans is uninteresting).

                    1. 3

                      I hacked on a Date-inspired relational DSL for a bit that addressed some of the things in this article. It included relation literals so you could do like:

                      left:
                      v :left_id :l :foo
                      v not_foo
                      Outer
                          | :right_id | :left_id | :r |
                          -----------------------------
                          | 1         | 1        | 11 |
                          | 2         | 1        | 12 |
                          | 3         | 2        | 23 |
                      ^ :new_header value 9
                      

                      Warning: the interpreter was v much written in a hurry.

                      1. 2

                        This looks almost cool. I’m surprised they don’t mention Datalog or its various recent siblings and children. I’m mostly surprised since the set flavored semantics they mention. Which very easily turns into stuff like monoids a la Haskell/ abstract algebra, as well as sane semantics on set valued computations forcing most/all functions/operations having some sort of monotonicity.

                        I could also just be totally misunderstanding the design I’m lazily guesstimating they have! :)

                        1. 1

                          I’m currently writing about some ideas on putting some funcprog influenced stuff into a relational query language, but I have it on hold for now while I read Codd’s The Relational Model for Database Management.

                          Stories with similar links:

                          1. We Can Do Better Than SQL via siddhantgoel 1 year ago | 76 points | 45 comments