I thought the whole point of Linq-to-SQL and Entity Framework was to take the SQL out of development?
I definitely understand what you're saying though. My boss uses Toad for everything even if it means many more steps than writing a simple update statement. She's just not interested in learning the queries.
As far as new features go, coming from the Oracle side of things, these features are almost always geared towards the DBA and not the developer, so I tend not to pay too much attention.
I have found there are generally two types of developers (with respect to databases):
- Developers who started writing applications and discovered databases were a useful place to store data. (I am this type).
- Database admins who discovered that they could code up a better UI for their database.
Type 1 developers tend not to see database as anything other than a data store and these are the devs who tend not to be interested in new SQL developments. They are also the majority of developers
Type 2 devs tend to want all the logic in stored procedures, while Type 1 want it all in code.
The other issue is that Type 1 developers tend not to be so good at SQL. I can string a complex SQL statement together, but it's a struggle and they tend not to be performant. SQL takes a different kind of thinking than OOP and I'm just not there yet.
We briefly had a Type 2 developer at our company (he mistakenly thought he was going to be included in redundancies and got another job before we told him we wanted to keep him), and he did things like rewriting an old stored proc that took 3min 45 seconds to a version that took 15 seconds. Useful guys, Type 2s.