13 ms·

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other v

• xiaodai 6y ago
  yeah the edgeql syntax just looks messy and the doc doesn't even explain how to do a group by
• enjo 6y ago
  XKCD’s comic on competing standards feels appropriate here: https://xkcd.com/927/ https://xkcd.com/927/
  • agumonkey 6y ago
    is xkcd ever not appropriate ? there's probably an xkcd about it
    • kybernetikos 6y ago
      Not a munroe original, but I like this one https://thomaspark.co/2017/01/relevant-xkcd/ https://thomaspark.co/2017/01/relevant-xkcd/
      • agumonkey 6y ago
        oh I thought he did that :)
  • CodesInChaos 6y ago
    I don't think treating query languages as a standard is the right comparison here. I think it's great that programming languages have evolved from C or PHP quality languages. I view SQL like PHP, I can write it if I have to, but it's certainly not a language I enjoy working with. EdgeQL has its flaws, but it still looks like a big improvement over SQL to me.
    • WesleyJohnson 6y ago
      I must be in the minority. I enjoy writing SQL and figuring out clever ways to construct queries to get what I need out of the data. Conversely, I am not a fan of PHP at all, but as you said, will write it if I have to. EdgeQL looks... interesting, but I need to see more to decide for sure. Would be cool if they built out a translator, so you could pass in SQL and get back EdgeQL.
      • CodesInChaos 6y ago
        It's a translator, but in the opposite direction. EdgeDB is a postgres frontend that translates EdgeQL and its schema definition language to SQL which it then sends to postgres. (It can also translate GraphQL to EdgeQL to SQL) I don't think translating from SQL to take a look at the EdgeQL it produces makes much sense, since it'd result in very unidiomatic queries. SQL prefers joins and flat rows, while EdgeQL is based on following links and has great support for nested data output.
• sfvisser 6y ago
  > SQL is messy because describing the underlying data relationships are messy. Not sure that is true. You can imagine having a smaller query language with clean semantics able to capture messy data relationships. Small functional expression languages come to mind. Where it lies on the spectrum from purely-table-form to can-hold-everything is a design choice. Your query language doesn’t need to capture the underlying data model exactly. SQL is an example of this itself. I’ve run into the orthogonality issue myself several times. You don’t need to drop SQL today, but for some data domains more expressive query models can work really well.
  • deleted 6y ago
    [deleted]
• 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 ago
    This is what we are trying to do with Cayley https://github.com/cayleygraph/cayley https://github.com/cayleygraph/cayley
    • woile 6y ago
      The website needs a link to the documentation, I just couldn't find it :/
  • p4bl0 6y ago
    Are 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 ago
      Came 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).
• unityByFreedom 6y ago
  I completely agree with both the title of this post and your comment. The solution is in diagrammatic "languages"/tools like Airflow, not more query languages. Selecting columns before tables always felt weird to me. Doesn't it make more sense if you had a graphical view this way? (imagine boxes around the below items where you can drag lines to make connections between tables/inputs) USERS --user_id-- [data processing] => ... GROUPS In SQL that would be, SELECT * ,groups.* from users INNER JOIN groups ON users.user_id = groups.user_id SQL is so messy and full of details that can be much better represented via dataflow diagrams.
  • 83457 6y ago
    There are graphical query generators in at least Microsoft's management tools. Most devs use straight SQL as far as I know because once you get into more complex queries the graphical interface becomes a hassle.
    • unityByFreedom 6y ago
      > There are graphical query generators in at least Microsoft's management tools The dev still needs to type the code first, which does not address any problems with SQL. > Most devs use straight SQL as far as I know because once you get into more complex queries the graphical interface becomes a hassle. Those interfaces may be limited, or the devs may not have enough experience writing "code" via a higher-level graphical interface. Going from writing SQL to creating dataflow diagrams may be a bit like switching from imperative to functional programming.
  • tsimionescu 6y ago
    Given our source control tools' limitations, I will take a textual format over graphical representation any day. Either way, queries need to be composed at runtime a lot of the time, so for many uses of SQL you can't just have the queries as blobs that you prepare ahead of time in some other tool - they must be objects you can work with programmatically.
    • 6y ago
• Areading314 6y ago
  Right, it's like criticizing python, or English, for being inconsistent, or "large". Turns out that doesn't matter -- what matters is that the language is useful because it has a wide base of users and libraries, just like SQL does.
  • m000 6y ago
    Python and English are meant to be general purpose languages, so they are kind of expected to be large and occasionally inconsistent. SQL is (by definition) a domain-specific language which has grown out of proportions. Are there really any SQL libraries in the traditional sense (i.e. reusable/composable SQL code with a well specified API)? SQL "libraries" typically focus on hiding the inconsistencies and the abhorrent syntax under the carpet. And the user base is there, mostly because of the database engine properties and features. The query language itself is just a bad side-effect. And TFA does make a point that NoSQL abandoning the underlying RDBMS model is in fact a regression.
    • deleted 6y ago
      [deleted]
    • bmh100 6y ago
      SQL is designed around databases. Python is designed around objects. Clojure is designed around expressions. A table is analogous to a list of objects. None of these languages is more domain-specific than any other.
    • Areading314 6y ago
      Perhaps libraries doesn't really apply to SQL per se, but instead you have tooling, ecosystem, DB engines, ORMs, extensions etc, that all speak SQL and would be hard to do without.
• IshKebab 6y ago
  I don't see how that makes them arrogant. SQL's implementation inconsistencies are a real problem. Their query language doesn't claim to be another version of SQL - it's clearly very different. Also that is only one of the things they are hoping to fix. It sounds like you're saying "We have 5 variants of SQL already so nobody is allowed to write any other database query languages ever. We must use SQL forever." which is stupid.
• roenxi 6y ago
  > SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments? Is "day from timestamp '2001-02-16 20:38:40'" the argument? Are the arguments "day", "timestamp" and "'2001-02-16 20:38:40'"? Are these annoyances crippling? Yes. Yes they are crippling. It should be possible for an amateur to quickly write an SQL validator as a starting project; relational algebra is not complicated. Any fool can write a validator for lisp. Relational algebra isn't that much more complicated - we don't have loops or flow control to contend with here. Tidyverse's dplyr [0] implements the relational model for real dirty data and, as might be expected for something implemented this century, does a much better job than SQL. Not because the operations are that much different (although gather() & spread() are welcome additions) but through ingenious innovations like, as mentioned, functions having arguments instead of I-don't-even-know-what-that-is. And the pipe operator which is legitimately ingenious. Great operator for data. [0] https://dplyr.tidyverse.org/reference/index.html https://dplyr.tidyverse.org/reference/index.html
  • thom 6y ago
    Except that dplyr is horribly slow and memory inefficient, and (if you were minded to actually put R code into production) it more or less forces you to do data prep in a database anyway.
  • ideamotor 6y ago
    Please use pivot_wider and pivot_longer instead of gather and spread. The true horror, even admitted by the the dplyr team ...
    • roenxi 6y ago
      Oh, they're new. Great. Thanks for the tip.
  • krick 6y ago
• bryanrasmussen 6y ago
  >It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... Obligatory XKCD https://xkcd.com/927/ https://xkcd.com/927/
• josefrichter 6y ago
  the first paragraph of your response was unnecessary, or perhaps could have been worded more constructively
• gwbas1c 6y ago
  In a world where there's a new programming language every other month, what's wrong with suggesting a new query language? At least we don't have to change our whole data model or give up consistent data to try it!
• goto11 6y ago
  > SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax.
  • gboss 6y ago
    Slightly tangential but I really like Linq syntax. The only problem I have with it is that it is really hard to debug if there is a logic error. I often see developers write linq find out the record set they get back is incorrect and then break up the linq query to a nested if clause to get what they want.
    • nightski 6y ago
      Yeah I feel like that happens whenever you have a mapping from one language to another. Eventually you learn the intricacies of the transformation. There are very few situations where the Linq I write does not translate into the query I expect any more. But that took time to learn. The only criticism I have of Linq is that it is a more general language targeting different back-ends including plain old objects. If Linq did not allow things that do not make sense in SQL this would be a little less jarring. I also wish it supported full outer joins, unions, and window functions.
      • scarface74 6y ago
        I was amazed the first time I used the MongoLinq driver. It makes sense intuitively, but the idea that you can use the same Linq expression and it will be translated to either Sql or MongoQuery based on the provider you send it to was amazing. I was able to hire a four or five contractors who never used Mongo just by requiring Entity Framework/Linq experience and less than 4 hours of training.
• asdfasgasdgasdg 6y ago
  SQL is messy because describing the underlying data relationships are messy. The article presents several examples where SQL's messiness cannot be plausibly attributed to underlying data relationship messiness.
• joshsyn 6y ago
  Most relationships, I have encountered are just one-many, many-one, many-mane, one-one, indirect, direct or graphical in nature. You want flat result, aggregated result. Why does this have to be blamed on the data relationship and not SQL language itself? For any graphical type of relationships, I find SQL utterly hard to express my queries properly. It feels like a assembly language at that point.
• 013a 6y ago
  A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more consistent and beautiful querying languages than SQL: I would point to MongoDB's query language, which is less of a query language and more of a static javascript-interpretable library, but is still far easier to learn and more consistent than SQL. The same query in MongoDB: "db.users.find({ foo: "bar" });". How is this better? It embeds the operation in the statement ("find"); reading it hierarchically follows how the data is stored (Collection > Rows); the filtering operation is the same shape as the data being stored; and it naturally disallows most injection attacks.
  • jolux 6y ago
    That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORMs (really query builders) already provide behavior like this against SQL databases anyway.
    • throwaway894345 6y ago
      And those ORMs have to deal with the SQL composability issues as well, often to the effect of dramatically poorer performance.
      • romanoderoma 6y ago
        I think Elixir ECTO does a very good job at that https://hexdocs.pm/ecto/Ecto.Query.html#module-composition https://hexdocs.pm/ecto/Ecto.Query.html#module-composition
      • jolux 6y ago
        You’re right, using a query layer to access an SQL database is still using an SQL database. You need to know what you’re doing with your queries. The important part is not the object mapping and model tracking part, it’s the part that allows you to build typed queries in the native language. Diesel for Rust is a great example, as is Ecto in Elixir.
• zadkey 6y ago
  https://xkcd.com/927/ https://xkcd.com/927/
• wtetzner 6y ago
  I think the real problem is that SQL text is the only interface to most relational databases. There is a SQL standard, of course, but it's difficult to get vendors to implement the standard, because SQL is the user interface to the database. Instead, perhaps a second format should be standardized, which is machine readable/writable, that more or less represents relational algebra + whatever extra features SQL supports. It can be clunky and verbose, as long as it's straight-forward and easily composable. It would effectively be like a compiler intermediate representation. Once you have something like that, you can have as many front-ends as you want with whatever syntax you prefer. Of course, getting all of the RDBMS vendors to agree to it is still a problem, and they'll probably all still include their own vendor-specific extensions and differences, because they want to lock you in to their system. But at least maybe the open source ones could agree, which would still be quite beneficial.
• oarabbus_ 6y ago
  >In that case, the result set is no longer a table, it's a dataframe, which is a useful data structure but is also not what relational databases do. What do you mean here? The difference between a table and a dataframe is that a dataframe is a construct held in memory, while a table is persisted storage written to a database.
• lowwave 6y ago
  It is very common to hear from new developers who are not familar with declaritve programming to complain about SQL. They don't tend to see the SQL syntqax fit into their 'programming' paradim. It is very simple, SQL is magic box, you ask it what you want, and it gave it to you. It is around for so long for a reason.