There are developers building solutions from a combination of application code (in C# for example) and stored procedures. Actualy, I am one of them. But this combination of skills is rather rare. In most cases stored procedures that operate on more than a single row are either build with cursors by programmers or are implemented separately by a DBA with some knowledge of the data contained in the database. Lately, code generated by an ORM is more and more poluting the database, allowing developers without ANY knowledge of good database design to use SQL server for data storage and retrieval.

Far too often I have to improve code that does all operations on a nested row-by-row base. Or even worse, code that first fetches all columns of all rows and then filters out the needed rows, finaly using less than a handful of columns. If you haven't come across such code in .NET, you may consider yourself a very lucky DBA. Did you ever come across such code and tried to explain to the developer responsible for that code how he (or she) could improve it by making better use of the capabilities of the database engine? For most developers, a relational database is just a bunch of tables. They might understand the purpose of adding domain and referential integrity constraints, but generally they will not know how and where to add them.

I'll expect some future version of SQL server will be tailored to work with code-first databases with a decent performance. After all, Micorosft is promoting this way of building solutions in nearly all examples of applications using a database and the Entity Framework. Some .NET developers may still have enough knowledge about relational databases to produce efficient code, but most programmers will asume that the performance and integrity of the data access layer is not their concern. If any of you did succeed in educating these programmers, please let me know, I'd love to hear more about that ...