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

21–30 of 354 posts

Re: Against SQL

#21

Post by NavinF »

>The usual response to complaints about the lack of union types in sql is that you should use an id column that joins against multiple tables, one for each possible type.

>create table json_value(id integer);

>create table json_bool(id integer, value bool)

>create table json_number(id integer, value double);

No, the usual response is "Don't do that!"

99% of the time you either know the data types (so each JSON object becomes a row in a table where the column names are keys) or you don't know the data types and store the whole object as a BLOB

I'd be on board with adding unions to SQL, but I doubt I'd use that feature very often.

Re: Against SQL

#22

Post by progre »

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.

Re: Against SQL

#23

Post by cm2187 »

saurik wrote: post #16
cm2187 wrote: post #12

One thing I don't understand in SQL is why creating a tmp table is so verbose, why we can't use type inference. There is an internal software where I work where to create a tmp table you just assign the result of the query to a variable. It is so much nicer. So for instance creating a tmp table becomes as simple as the below, no need to declare each columns, to do an insert, to drop the table in the end: @t = select…

You don't have to do all of those things though? Just create table as select (or sometimes select into).

Thanks. I didn't know this syntax. You still have to drop it in the end but somehow I never ran into this syntax.

Re: Against SQL

#24

Post by birdyrooster »

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…

No post body was provided.

Re: Against SQL

#25

Post by maxrev17 »

birdyrooster wrote: post #24
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…

Any more info? ;)

Re: Against SQL

#26

Post by dbsmith83 »

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

Re: Against SQL

#28

Post by kinjba11 »

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…

> maybe they are asking a bit much from SQL

But this article is thought provoking to say the least. It follows the courtroom logic of holding the defendant SQL on trial for as much as possible. And SQL is guilty of a lot of crimes.

I do hope GraphQL and similar query languages become more prevalent and standardized, as it seems SQL could really use some stiffer competition.

Re: Against SQL

#29

Post by pjmlp »

> 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 learned what views are for, and the various flavours they come in.

> 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
    inner join bar on foo.bar_id = bar.id
    inner join quux on bar.quux_id = quux.id
Really, how much time was spent learning SQL before complaining?

Re: Against SQL

#30

Post by yellow_lead »

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…

I agree with your last point to an extent. There's something about "inexpressiveness" that can actually be good, in that it requires you to simplify your data model. However, I imagine as it gets more complex, SQL becomes completely unwieldable. You basically have to use a NoSQL db as the author points out.
Post reply on HN