| |||||||||||||
A report from OpenSQLCampA report from OpenSQLCampPosted Nov 3, 2010 1:29 UTC (Wed) by ringerc (subscriber, #3071)In reply to: A report from OpenSQLCamp by nix Parent article: A report from OpenSQLCamp
I couldn't agree more. It tries to be a "natural" language, and instead lands up being horribly unnatural for both humans and computers to understand, stuck in some twilight zone middle ground, a sort of language purgatory.
I *love* the power of SQL, but the language its self I hate with a passion made all the stronger by the fact that it's too powerful NOT to use. I liken it to being forced to write in in LOLcode or leet because what you want to say can't be expressed directly in English; you may detest the languages, but to say what you want to you have to use them anyway.
I nearly said that I'd like to see the SQL standards body move to design an alternate SQL representation - but actually, I don't. I'd like to see a new query language widely adopted, possibly via a push from Sun/Oracle via the JDBC interface spec, and via Microsoft via the ODBC/ADO interface specs (and LINQ), so that it actually sees wide multi-vendor adoption. Alas, neither Oracle nor MS have a history of favoring interoperable, vendor-independent approaches to problems. We're kind of stuck with SQL, because nobody wants to agree on a replacement that doesn't suck, they all want to push their own interfaces that work with their database and no other.
(Log in to post comments)
A report from OpenSQLCamp Posted Nov 4, 2010 20:24 UTC (Thu) by lakeland (subscriber, #1157) [Link]
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>
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.
|
|||||||||||||