SQL

I barely escaped the Raleigh, NC, airport yesterday for a 6:08am flight. I'd never seen such long security lines so early, even on a Friday morning. But I made it, and there were others on my plane later than me. Just as the cold and rain was hitting NC, I'm back in OR on a sunny Saturday. We'll get more cold and rain, but we're definitely on the upswing into spring here.

Anyway...

Steve Dekorte writes about SQL...

The motivation for SQL queries being declarative was that you could just tell the database "what" you want... If something fails at it's primary reason for existence, is it time to reconsider it's existence?

I don't want to defend SQL too much -- even the declarative expressions have their faults -- but most of the blame for so much "imperative" SQL has to do with the database implementations themselves. The first 15-20 years of the relational database market were aimed at OLTP on hardware with significantly less capabilities than we have today. There was relatively little emphasis on "relations" in the OLAP sense.

And so SQL had to become more imperative, account for explicitly created temporary tables, and incorporate "stored procedures" to perform the explicit, step-by-step operations.

If you look at database systems like Teradata (which is a highly concurrent, shared-nothing architecture), or column-oriented databases like SybaseIQ or C-Store then you will find the ability to program SQL queries as originally intended, in a functional style. I wrote some SQL for Teradata ca. 2001-2003 and helped others improve their SQL (who had been using primarily SQL-Server and T-SQL) because I had a good bit of Lisp and functional programming experience.

Programming truly declarative SQL and the more common procedural SQL are very different experiences. But it is possible, if the underlying database architecture will support decent performance for declarative queries.