It was interesting at the MSDN Roadshow yesterday to see one DB developers reaction to LINQ. His attitude was a common one from the DB community toward ORM products that use dynamic sql that ‘real applications use stored procedures’. Usually the concerns people have center around peformance and security.
In that light it was interesting to note the following snippet from QCon then via Ferren Rodenas:
they don’t use stored procedures, triggers and, amazing, nor transactions (Martin Fowler is talking about this in his post Transactionless). This means that all business logic is executed by the application (sorts, joins, referential integrity, …). They use intensively prepared statements an bind variables (cached by datasources). They also scales using a rewritten connection pool and an internally developed ORM solution called DAL (Data Access Layer). All CRUD operations are executed through this infrastructure.
There is a full PDF here.
It it too particular an example to form a general pattern. Nevertheless, I would hope that the fact that eBay have chosen to use an ORM, don’t use stored procs or transactions, and keep all their logic in the domain layer will make a few more people at least question the sacred cows they have around these techniques. Particularly the broad assumption that domain focused applications don’t scale or are unpeformant would seem to be very questionable, because Ebay appears to be using them for the very reason that the provide better scalability.
On security, I have said before that I believe the main reason why people demand stored procedures is because they want a boundary. When you cross the boundary from the application domain into the DB domain it is easy to become involved in border disputes. In an enterprise the databases are often owned outside the development team, which reinforces the notion of boundaries and uncontrolled access as tresspass. I suspect that DB teams like stored procedures because they are good fences to stop the developers roaming over their territory. They give them the feeling of control over what happens on thier ‘turf’. Application developers often hate them because they find the restrictions on their freedom make it much more difficult to get thier work done. The corollary is that when a development team owns its own DB, these disputes are far less common. What we end up with though resembles a range war with free-ranging developers fighting a DB team determined to fence them in.
The sad thing here is that what the DB team are controlling is often low-value, low-risk CRUD statements. This is all that a lot of the dev teams using ORM tools are replacing. Those CRUD statements are not an area where DB devs add real value. Most are simple and mechanical. Sometimes the DB team even generate them using CodeSmith templates themselves. In that case they can’t believe they really need hand optimization, so why not let the application developers ‘generate’ them. There are other ways to control security of your data, such as using the identity the application impersonates.
I would say to the DB devs that if you are fighting for stored procedures to fence in the application devs it namy now be time to let them roam freely across the transactional store. Move your fences to the OLAP database, That’s where a smart DB Dev can use BI tools to add genuine value to the business.