You Can Do It in SQL, Stop Writing Extra Code for That

Re:You Can Do It in SQL, Stop Writing Extra Code for That by wolfgang42 on Friday December 14, 2018 @02:00PM (#18683519)

Relational databases are brilliant, but SQL is terrible and I don't understand how it hasn't gone the way of COBOL yet. For a start, the bizarrely English-oriented structure forces a completely different ordering of the code than what comes out, and the syntax appears to completely ignore the underlying tabular concepts. Not to mention that IMO joining on foreign keys shouldn't be a thing--the database should be able to figure out what you want when you write `order.customer.address.taxRegion.rate` without specifying any joins at all. Even if you use an ORM you still have to understand the code it will emit to avoid building bad queries. There's just so much awkwardness in trying to write a SQL query that I can definitely see why people would avoid it.

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by user2426679 on Friday December 14, 2018 @06:39PM (#18685914)

> Relational databases are brilliant, but SQL is terrible and I don't understand how it hasn't gone the way of COBOL yet.

Having written extensive amounts of SQL and greater than zero lines of COBOL (f. you, Lawson), this really couldn't be further from the truth.

> For a start, the bizarrely English-oriented structure forces a completely different ordering of the code than what comes out, and the syntax appears to completely ignore the underlying tabular concepts.

Every language has keywords; I'm not sure how you expect to write code that doesn't involve English in some form. Is the concept of `SELECT this_data FROM this_source WHERE true_conditions ORDER BY columns` really that convoluted? Sure, it definitely gets more complicated, but is there really a significantly better way to do it that doesn't involve taking away low-level control from the programmer, in exchange for something sexier and easier to pick up?

> Not to mention that IMO joining on foreign keys shouldn't be a thing--the database should be able to figure out what you want when you write `order.customer.address.taxRegion.rate`

Why can't you have a key-value storage engine that doesn't involve using keys to look up values?! (Is that really your question?) Okay, just as an example, what if you have more than one address for a customer? You need a way to tell the engine which address(es) you want.

> There's just so much awkwardness in trying to write a SQL query that I can definitely see why people would avoid it.

While I don't claim that SQL is easy (or always intuitive), saying that it is "terrible" for the above reasons is like saying that C is terrible because it's not Pythonic.

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by natalyarostova on Friday December 14, 2018 @06:52PM (#18685998)

I'd prefer it if C were more pythonic tbh.

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by cultofmetatron on Friday December 14, 2018 @07:03PM (#18686044)

sooo..... go?

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by peatmoss on Friday December 14, 2018 @02:55PM (#18684049)

The brilliance of RDBMSs is the relational algebra. But, I agree SQL can sometimes feel a little verbose / obtuse.

I’ve had learning datalog on my todo list for a long time. I’d love to see some other DSls for the relational algebra as well

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by contingencies on Friday December 14, 2018 @04:20PM (#18684895)

Re: Verbose/obtuse. There are different ways to use SQL. For example IMHO if you use the unnecessary "<LEFT/RIGHT> JOIN" syntax then statements often come across as pretty unreadable, whereas you can generally achieve the same with alternate and more readable syntax.

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by tfehring on Friday December 14, 2018 @08:49PM (#18686524)

As opposed to SELECT * FROM a, b WHERE a.id = b.id? Looks ok on paper, but in exchange for brevity you end up demolishing your readability on complex queries, since you can’t easily identify filters (as opposed to join conditions). Most style guides, including my team’s, consider explicit JOINs mandatory, and there’s a good reason for doing so.

Admittedly my work is very heavy on data manipulation; maybe complex queries are less of a concern for other use cases.

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by contingencies on Saturday December 15, 2018 @02:05AM (#18687433)

you can’t easily identify filters

I'm not often SQL wrangling these days, so you are probably more aware than I am on intricacies, but often you can wrap subqueries like:

  SELECT stuff FROM tables WHERE conditions AND table.field IN (
    SELECT othertable.otherfield FROM othertables WHERE more_conditions...)
  );

IMHO this reads far more easily and both depth and order of execution are clear. I guess at this point in my career (20 years in) my bias is toward code I can walk away from for years and come back to easily.

Clarity is better than cleverness. - Eric S. Raymond, The Art of Unix Programming (2003)

He's got a point. Quote via http://github.com/globalcitizen/taoup

[ Parent | on HN ]

Re:You Can Do It in SQL, Stop Writing Extra Code for That by rpz on Friday December 14, 2018 @08:11PM (#18686362)

Kdb has foreign key equi-joins built in just like you mention. You can see how it looks under the notes section here https://kparc.com/d.txt

[ Parent | on HN ]