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 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 ]