5 ms·

I'm disappointed that there isn't more criticism of the SQL language. The whole NoSQL buzz got me excited, then turned out to actually mean NoRelational. It is

• nouveaux 7y ago
  In regards to 'select' before 'from', there could be a similar argument to be made for declaring imports at the top of a file. When you write a program, you may not know what libraries you need. Variable declaration at the beginning of a function is also a common pattern. The SQL language stood the test of time where as COBOL did not. I think it says something about how well it was designed. I strongly suspect that developers have such a hard time with it is because of ORM. ORM trains you to think of the database as objects. Another poster mentioned that treating databases like sets made SQL click. I think that is a good way of thinking about SQL. To be fair, SQL does have some archaic things in there that make it annoying to work with. However, once it clicks, it's fits naturally with how a relational db works.
  • setr 7y ago
    >Variable declaration at the beginning of a function is also a common pattern What language requires you to declare variables at the beginning? C even stopped doing that. People choose to do that, but ime that's after the writing phase, to make it more readable >When you write a program, you may not know what libraries you need Sort of -- the difference is that when I'm writing code in my IDE, I know all database objects available to me. It's in the schema. A library I import once (to the project itself), and the IDE can always assist from then-on. But SQL is designed such that despite the library (schema) being imported, the IDE can't actually assist, unless I write the code out of order (eg start with SELECT * FROM table and then start working) >However, once it clicks, it's fits naturally with how a relational db works I think you've misunderstood the complaint -- the relational language is a very strong concept, which has stood the test of time, and is difficult to complain about -- it does its job well, and fits naturally with how a relational db works. SQL the language however is: A hodgepodge of random keywords tossed about in a totally inconsistent fashion (eg postgres overlay: OVERLAY('Txxxxas' PLACING 'hom' FROM 2 FOR 4) -- postgres at least generally offers a consistent comma-separated syntax for every functions has weird and technically unnecessary limitations (like SELECT being evaluated after the WHERE clause, so you can't use the aliases defined in select clause) putting SELECT before the FROM (disabling IDE auto-complete support) the stuffing of a 3-value logic system into a 2-value logic interface, so boolean operations break silently and produce nonsense in the face of a database with NULL values, because no mapping of NOT (TRUE, FALSE, NULL) AND NULL makes sense. [0] It generally composes very poorly, leading to redundant, long and convoluted queries The MODEL is fantastic -- the language is not. [0] https://sigmodrecord.org/publications/sigmodRecord/1709/pdfs/03_principles_Guagliardo.pdf https://sigmodrecord.org/publications/sigmodRecord/1709/pdfs...
• a_c 7y ago
  SQL stood the test of time. SQL is widely adopted. Once you get the hang of it, it can be applied on a wide range of RDBMS. I would argue that countless productivity has been lost to learning yet another query language for yet another NoSQL db. Mongo has its own query language. Cassandra has its own. Neo4j has its own. What not. Guess what, few engineers need these to solve their actual problem. Be it building an application, a library, a SaaS, a tool with wide database support. The yet another query language is an imaginary solution to an imaginary problem (most of the time). Your problem isn't big enough to use whatever NoSQL of choice. When developers starting out, they get attracted to technologies with the most marketing money. They beat around the bush of learning things that might not matter anymore 5 years down the road. Is english the best language? No, not even close. Should one learn it? Probably. Is esperanto a better language? I don't know, maybe. People invent it for a reason (a problem to solve) after all. Should one learn it? Probably no.
  • strbean 7y ago
    > SQL stood the test of time. SQL is widely adopted. I'm highly dubious of "it is widely used so there" arguments. I think in the case of SQL, the fact that ORMs and SQL generators are ubiquitous are evidence that a huge proportion of engineers would rather not write it, and part of why it is still widely used (most of the time, most people can avoid actually touching it). > I would argue that countless productivity has been lost to learning yet another query language for yet another NoSQL db. Mongo has its own query language. Cassandra has its own. Neo4j has its own. What not. Guess what, few engineers need these to solve their actual problem. This is exactly one of the points I addressed in my comment... none of those are even relational databases. And this is where the discussion ends up every time someone says SQL sucks. > Is english the best language? No, not even close. Should one learn it? Probably. The vast majority of the time, when you are using English, you have no control over the receiving end. The vast majority of time, when you are using SQL, you / your org grabbed an SQL RDBMS to use. Furthermore, I don't see why a modern, reasonable query language couldn't transpile to SQL easily when necessary, making all path-dependency / adoption arguments void.
• jiggawatts 7y ago
  I agree. The SQL language is in desperate need of an "upgrade" to a proper functional language. It's missing so many basic features that it's just painful. For example, why do I have to repeat expressions in the SELECT, GROUP BY and ORDER BY clauses!? E.g: SELECT LEFT(Foo,4) as Prefix, COUNT(1) as N FROM MyTable GROUP BY LEFT(Foo,4) ORDER BY LEFT(Foo,4) This gets really obnoxious for complex expressions. I mean sure, I can break things out into functions, or use the WITH clause, but both of those often end up being more verbose, not less. This is solved in functional languages such as Haskell with the "where" or "let" clauses (not to be confused with the SQL WHERE filter). I wish I could do something like: SELECT Prefix, COUNT(1) as N FROM MyTable GROUP BY Prefix ORDER BY Prefix LET Prefix = LEFT(Foo,4) Similarly, it's crazy to me that most SQL dialects don't allow relational functions to be passed around as proper data types. This kind of thing comes up a lot when implementing row-level security. I'd like to be able to write "view functions" that can take any relation as an input, as long as it contains some column, and then add on some joins or filters based on that column. Imagine you have a bunch of tables that link to the "Customers" table via a "CustomerID" column or whatever. It would be great to be able to natively write a query that says "AddCustomerName" or "FilterDisabledCustomers". These would take an existing relation (table/view/function) as an input, and return a new relation as the output with an extra column or filtered rows. This kind of modular style made up of small chunks of code that can be elegantly composed is just not possible or very messy in most SQL platforms. It's typical of most modern functional languages, and I think the "next gen" query language that replaces SQL will look more like Haskell and less like COBOL.
  • projektfu 7y ago
    Select Prefix, count(1) as n From (select LEFT(Foo,4) as Prefix, * from mytable) GROUP BY Prefix ORDER BY Prefix
• wenc 7y ago
  > Wouldn't it help to have a language for working with it that isn't outright terrible? There is a language like that, and it's downright elegant. It's called LINQ, and it's built into the C# language. It inverts FROM and SELECT, which lets it reliably support autocomplete. LINQ was built using concepts from category theory/relational theory and is widely used in C# to make code tighter and simpler (even though some eschew it because simple for loops are faster). It also transpiles to SQL via Linq-to-SQL. It looks like this: var results = from c in collection where c.Fld1 < 10 select new {c.Fld1, c.Fld2}; It's the closest thing we have to SQL that Typescript is to Javascript. That said, most people who access databases in C# still either write SQL or use an ORM like EF or Dapper. Databases speak SQL natively for better or for worse. And the SQL language, despite its flaws, is actually mathematically very deep because it's been developed and extended over so many years. See [2] for some serious SQL-fu. To replicate all this functionality into a new language that transpiles into performant SQL is a huge undertaking. SQL is one of those incumbents that is extremely hard to displace, partly because it's so ubiquitous and that in practice, not everyone finds outright terrible. True, it's not good, but it's not terrible. I write it day in and day out. The analogy I can think of is the Erlang language -- it doesn't have a pretty syntax but it solves the concurrency problem really well. SQL for better or for worse solves the complex analytic query problem really well. [1] https://en.wikipedia.org/wiki/Language_Integrated_Query https://en.wikipedia.org/wiki/Language_Integrated_Query [2] https://modern-sql.com/slides https://modern-sql.com/slides