User: Password:
|
|
Subscribe / Log in / New account

A report from OpenSQLCamp

A report from OpenSQLCamp

Posted Nov 4, 2010 20:24 UTC (Thu) by lakeland (subscriber, #1157)
In reply to: A report from OpenSQLCamp by ringerc
Parent article: A report from OpenSQLCamp

Make that 'me too' :)

SQL reminds me of HyperTalk from the late 80s, designed to be almost a native language but failing in awkward ways, and at the same time making it very hard to with with pro grammatically.

<RANT>

Have you used SAS? One of the interesting features of SAS is that you can manipulate your data using both PROC SQL and DATA steps. That's interesting because some operations are far more naturally expressed in DATA steps while others are far more naturally expressed in PROC SQL. I know nobody likes RBAR but sometimes it's the easiest way to solve a problem. Much like Microsoft have cripplingly bad string manipulation in SQL Server and say they won't fix it because string manipulation is slow. Perhaps true, but sometimes you care more about getting your job done simply than how hard the machine has to work.

Even when SQL has a natural approach I find the language unnecessarily awkward, like s how in every SQL variant (except MySQL), you cannot say GROUP BY 1 but instead have to copy/paste your select clause, or how you cannot make table names variable, or how the first condition clause is prefixed with WHERE and others with AND.

Another issue is how hard it is to work with GROUP BY... Say I'd like to display the best customers in each region, you'd think I'd be able to do something like

select * from customer where customer_id in (select customer_id from customer group by region having score = MAX(score) PARTITION BY REGION)...

You can see the whole thing is turning into a mess and it is not finished yet. Yet the problem was incredibly simple to specify precisely - anything that easy to specify precisely should be easy to do.

Another thing which Postgres does well but no others do is have a really elegant way of shifting to a slightly more powerful language when SQL doesn't quite do it for you.

Why is it that DB vendors seem to think supporting a feature is adequate and making it easy to use is optional? One thing I really like about SQL Server and to a lesser extent MySQL is that they go out of their way to make their nonstandard SQL extensions easy to use. For instance, ISNULL might have some dumb behaviours but it's so much better named than COALESCE, and have you looked at how awkward the spatial syntax is in MySQL, Postgres or Oracle?

</RANT>


(Log in to post comments)

A report from OpenSQLCamp

Posted Nov 14, 2010 0:49 UTC (Sun) by jberkus (subscriber, #55561) [Link]

All,

Thanks everyone for the rants on why you hate SQL. The above gives us SQL geeks some useful feedback on what to focus on (or what to avoid) when teaching people to live with SQL.

I happen to like SQL a lot, although I can certainly imagine an alternative, better data manipulation language (XLST doesn't cut it, sorry). I understand that a lot of people don't, just as SGML and XML give me the hives, yet there's people who adore *them*. For that matter, I like Perl and C.

Oh, and PostgreSQL does support GROUP BY 1 (it's in the standard). I recommend against it, though, because it's a foot-gun.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds