

Awesome SQL blog - niklas
http://explainextended.com/

======
sivers
Fans of this will probably also like Joe Celko's SQL for Smarties. ISBN:
0123693799

It's unfortunate that a lot of new programmers are relying on their
framework's ORM to abstract the SQL away from them, weakening their
understanding of it.

~~~
kingkilr
I think that's a little unfair to people using ORMs. Obviously I'd hope people
don't want to avoid knowledge, but I'll be damned if I want to write SQL, it's
not fun for me. That being said I contribute to the ORM of my framework of
choice, if I write the solution to my problem once I'll never have to do it
again. I think it's a bit like complaining that C programs are trying to
abstract away assembly. Yes they are, but as long as they have some level
understanding of how machines work they'll be ok, and a hell of a lot more
productive.

~~~
samuel
Personally I don't get ORM's. May be it's because the only I have had to deal
with was Hibernate, and seemed to me as an innecesary layer of complexity and
bloat, and objects and relations sometimes doesn't map nicely. If you want to
persist objects, use an object datastore in the first place, not a relational
one.

And, what's wrong with SQL? It's simple, powerful, widely known and deployed,
and cool(declarative programming, dude!).

I've read a some introductory examples about distinct ORM's and just don't get
it. Where's the gain? Apart from database independence(which I don't think
it's even desirable in most cases, may be Tom Kyte's books have brainwashed me
irremediably), can't see one. How an ORM makes you more productive?

~~~
gaius
The people who hate SQL don't know about any of the cool stuff it can do as
they've only ever used MySQL's very basic implementation.

------
russell
It's an excellent cookbook of useful SQL queries with well written
explanations. I've used SQL for decades, but after reading a few articles, it
was obvious that I could learn some new tricks. The articles are bite sized an
tasty.

~~~
quassnoi
Thanks!

------
leandrod
Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite
different and more complicated. And, by the way, CTEs are a feature of ISO
SQL, not only of MS SQL Server.

Finally, entity‐relationſhip is not terribly practical as a model, but as
diagrammiŋ.

~~~
pradocchia
This is true, SQL does not require everything to be a set, strictly speaking,
but internally many platforms append a unique row identifier to bags, so that
they can be processed as sets.

I often wish platforms would expose their internal calculus in a separate
syntax, so we wouldn't have to work through the SQL translation layer.
Algebraic operators would be nice too.

~~~
leandrod
Ðat may be true, but what platforms do internally ſhould not affect ðeir
flavours of SQL.

In oðer words, internal implementation as ſets do not make SQL ſet‐baſed.

~~~
pradocchia
No argument there (ðere?), SQL is an unfortunate language.

~~~
cturner
Do you have any thoughts about why there has been no challenge to the SQL
syntax? We can easily imagine notations based on relational algebra and
relational calculus emerging that could be interpreted at the same levels of
an RDBMS as SQL, yet I've not seen anyone attempt it. A good PhD topic for
someone?

~~~
encoderer
SQL was designed to make data accessible to non-programmers. That's why it
lacks more advanced/obscure syntax.

And the reason why it's stuck is the same story that you can tell over and
over about standards.

