Yes, I know, this is one of those articles that surely will make many people angry.
For years I want to stop seeing so much SQL in the applications I architect!
Why? Because I believe that DBAs are too much a limited and expensive resource to use for most of our application design. And because SQL by itself doesn't promote strongly typing, or Intellisense discoverability. Among others.
And so I'm a firm believer on ORMs. More, I believe that the problems stated in the The Vietnam of Computer Science will be largely surpassed by the benefits it brings - even before the arrival of the LINQ initiative.
So I keep dreaming on applications where only 5% of the relational algebra is made in SQL - 0% in the long term. And the dream is feasible for most of my application. Except for the #&%$"&%$# most applications must have: the migration!
Yes, for the migration we still must depend heavily on SQL. When the ORM war is over, we'll still have this one to battle.
And even those are nothing but intermediate steps on a much broader roadmap. But that's a story for a future posting...
1 comment:
I think the biggest problem is not the SQL or the mapping per se. The problem is getting developers to understand relational algebra and stop thinking in row-by-row mode.
The mapping, or the copy-paste, or code-generation is the smallest part of the problem. Teaching developers to think in sets and working with sets will be the toughest part. And that, no tool can alleviate.
By that, I don't mean that these tools/techniques are bad. Quite the opposite. They cut away much of the plumbing work that programmers do, and solve quite a few problems. And will also bring this hidden problem to the front row.
Post a Comment