If a DBA (or anyone) can demonstrate that hand-crafted code performs better than generated code, it's an everything problem.Everything, you say? Well then, you need to consider an Oracle SP since those are truly compiled, unlike SQL Server SPs whose performance differences from equivalent parameterized SQL aren't measurable. I don't see you advocating that. ;-)
In fairness, I suspect you are referring to L2S and its queries that sometimes- not always- became terribly inefficient. Other times they were remarkably elegant. Now that L2S is foxed I doubt we'll see improvement of the bad parts, but what do you think of EF4?
And for that matter, whether it's a people problem or technology problem, it's still a problem. Technology doesn't live in a vacuum.Not sure what you're getting at there. The people problem to which I refer holds that the DBA him/herself is as great if not more of a security risk than a masked bandit breaking in to select data. There is evidence: in one study looking at patient data privacy breaches, 75% was by IT staff and <5% was by external hackers. That the IT staff blocked CRUD access to thwart improper access by others isn't much of a security solution. ;-)
Nice talking but I'm off on a trip and won't be here for a while. As I said, take a look at POCO and see what you think. I think I like it- but as I said earlier, suspension of judgment still applies and I'm waiting for the big "uh oh" gong to sound. ;-)
"... They ne'er cared for us
yet: suffer us to famish, and their store-houses
crammed with grain; make edicts for usury, to
support usurers; repeal daily any wholesome act
established against the rich, and provide more
piercing statutes daily, to chain up and restrain
the poor. If the wars eat us not up, they will; and
there's all the love they bear us."
-- Shakespeare: Coriolanus, Act 1, scene 1