Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against SQL

scattered-thoughts.net

Post reply on HN
Print view View original

41–50 of 354 posts

Re: Against SQL

#41

Post by james_woods »

SQL was not made for programmers alone. It has been invented also for not so technical people so that verboseness and overhead is part of the deal.

>When Ray and I were designing Sequel in 1974, we thought that the predominant use of the language would be for ad-hoc queries by planners and other professionals whose domain of expertise was not primarily data- base management. We wanted the language to be simple enough that ordinary people could ‘‘walk up and use it’’ with a minimum of training.

https://ieeexplore.ieee.org/document/6359709

Re: Against SQL

#42

Post by pdkl95 »

erezsh wrote: post #17
chris_wot wrote: post #5

This isn't just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write. 20% longer to write than what alternative? And how is this being measured? And.. am I missing something? By far the most common case for joins is following foreign keys. SQL has no special syntax for this: select foo.id, quux.value from foo, bar, quux where foo.bar_id = bar.id and bar.quux_id = quux.id Why can'…

> Why can't this be expressed as an INNER JOIN? `from foo, bar, quux` is an inner join, it's a shorthand syntax. He's lamenting that he has to keep specifying and matching ids, when the database can figure it out on its own from the foreign keys.

They should use NATURAL JOIN if auto-selection of the join keys is that important. I wouldn't recommend relying on that type of automagic behavior because it is very brittle; adding a column to a table might accidentally break existing queries.

Re: Against SQL

#44

Post by zozbot234 »

roenxi wrote: post #20

One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn't use function(arg, arg, arg) It is strange that "SELECT a, b, c FROM schema.table" keeps any aura of respectability. That is legitimately outdated syntax, people don't write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and…

Mixfix syntax is not that weird. Objective-C is one well known language that uses it, for example.

Re: Against SQL

#45

Post by pjmlp »

roenxi wrote: post #20

One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn't use function(arg, arg, arg) It is strange that "SELECT a, b, c FROM schema.table" keeps any aura of respectability. That is legitimately outdated syntax, people don't write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and…

Here is your function(arg, arg, arg)

    CREATE [OR REPLACE] FUNCTION function_name (arg, arg, arg)
        RETURN return_type
    IS
      ---
    END;
Then

    SELECT function_name (arg, arg, arg...) FROM dual;


    SELECT columns FROM xpt where xpt.id = function_name (arg, arg, arg...);

    IF function_name (arg, arg, arg...) = ... THEN ...

Re: Against SQL

#46

Post by kinjba11 »

progre wrote: post #22
chris_wot wrote: post #5

This isn't just a matter of some constant programmer overhead, like SQL queries taking 20% longer to write. 20% longer to write than what alternative? And how is this being measured? And.. am I missing something? By far the most common case for joins is following foreign keys. SQL has no special syntax for this: select foo.id, quux.value from foo, bar, quux where foo.bar_id = bar.id and bar.quux_id = quux.id Why can'…

While some of their complaints are legit I think most of the SQL in this article are straw men. Most of it can be made more readable and more performant.

Care to back up those claim with evidence? The SQL queries are toy examples. Experienced SQL users don't write SQL like in the article because they know SQL's pitfalls and avoid them. It doesn't mean SQL isn't full of pitfalls and bad decisions (like many very old programming languages still in use).

Re: Against SQL

#47

Post by bokwoon »

pjmlp wrote: post #29

> Why did SQL have to add it to the language spec? Most likely because there isn't cargo for SQL, everyone has to make do with a default install offers, and most big boys databases offer FFI to Java, .NET and C. > This works for data modelling (although it's still clunky because you must try joins against each of the tables at every use site rather than just ask the value which table it refers to) Only if one never l…

Given that the author also wrote https://scattered-thoughts.net/writing/select-wat-from-sql/, I don't think he knows nothing about inner joins. I think he was just using that equivalent form to compare it with the terser `foo.bar.quux`. It is pretty strange to compare it with `fk_join(foo, 'bar_id', bar, 'quux_id', quux)` though, because SQL already has the equivalent `foo JOIN bar USING bar_id JOIN quux USING quux_id`.

Re: Against SQL

#48

Post by mongol »

dbsmith83 wrote: post #26
roenxi wrote: post #20

One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn't use function(arg, arg, arg) It is strange that "SELECT a, b, c FROM schema.table" keeps any aura of respectability. That is legitimately outdated syntax, people don't write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and…

Comparing SQL to those other languages doesn't really make sense. Their purpose is different. For what SQL does, the syntax makes a lot of sense because it is a completely different paradigm. I think it's dismissive to refer to SQL as merely a 70s experiment. It is used so widely today still

I think SQL is amazing. There are few technologies within IT that has held up as well as it has. Skills you could gave learned 40 years ago still useful today. I think learning SQL well is one of the best investments you can do in yourself.

Re: Against SQL

#49

Post by qPM9l3XJrF »

progre wrote: post #14

I do love SQL and at least where I live (MS SQL Server) it can be made to run amazingly fast if you take some care with your queries and indexes. It's not portable though: as far as I know not a single one of the big sql vendors follows the standards 100% and more importantly, spending some time with one vendor will give you some habits that are sure to not work as well with another (cursor constructs are generally a…

>spending some time with one vendor will give you some habits that are sure to not work as well with another

It seems like having multiple vendors is only valuable if their products are to some degree differentiated, no?

Re: Against SQL

#50

Post by pjmlp »

bokwoon wrote: post #47
pjmlp wrote: post #29

> Why did SQL have to add it to the language spec? Most likely because there isn't cargo for SQL, everyone has to make do with a default install offers, and most big boys databases offer FFI to Java, .NET and C. > This works for data modelling (although it's still clunky because you must try joins against each of the tables at every use site rather than just ask the value which table it refers to) Only if one never l…

Given that the author also wrote https://scattered-thoughts.net/writing/select-wat-from-sql/ , I don't think he knows nothing about inner joins. I think he was just using that equivalent form to compare it with the terser `foo.bar.quux`. It is pretty strange to compare it with `fk_join(foo, 'bar_id', bar, 'quux_id', quux)` though, because SQL already has the equivalent `foo JOIN bar USING bar_id JOIN quux USING quux_…

Yeah, it reads like going down the path to write some SQL like parser without actually having used SQL in anger.
Post reply on HN