Sure. What I am saying is that I only know one database-centric developer who actually is _doing_ this with some success. Ambler seems to have the same experience.

My comment was not about the technology. I don´t really care much about which technology people prefer. It was a musing on development cultures.

The people I work with don´t test their stored procedures. Testing does not require specialized technology, as you say. You just have to do it and make sure it gives you some value – that stuff continues to work in the future.

I can´t use stuff without automated regression tests. It is going to fall apart, given enough time. Someone will probably complain about the complexity, and then suggest replacing the stored procedures with something else – like an ORM framework, or Cobol – which will also not work out in the long run if the underlying problem hasn´t been fixed. A couple of years later, this will repeat, in extreme cases causing a shift back to the original technology.

It really is this simple. Most failures are not caused by using the wrong technologies. It is caused by people misapplying them.

I’m not familiar with the Ambler/Sadalage book, but if they do discourage the use of stored procedures, I have to wonder what they have to say in the other 383 pages of their book.

I am missing one book from your references list, though. “Database refactoring” by Ambler/Sadalage.

Of course, they discourage the use of stored procedures because most DB-driven development got stuck in the 1970s, and consequently do not have automated regression tests. I have to say I have to agree on that one.

Sure, it was controllable, with FreeProcCache running every now and again, but that’s not really the point. It took memory that we would rather have seen go to the data cache (and so reduce the I/O load on the disks). The developers thought the same as you stated, lots of cached plans won’t harm anything, we have a big server.

I was just contesting your statement that multiple plan cache entries are “[usually] not a big concern with today’s x64 systems with lots of RAM etc.” They can still be a big concern even with lots of memory.

There were other side effects of this design too. A large (too large) ObjectandUserPermTokenStore being one of them.

It would be very interesting to know more about the 20Gb proc cache though, and/or more details on how it got that big. I can imagine that there must be a lot of ad-hoc (unparameterized?) SQL involved and that it builds up over a long time? Lots of system resources available for SQL server to not bump things out of the proc cache? And no maintenance plans forcing recompile? Was it controllable from the db-side, e.g. through sp_recompile?

With update statistics, maybe a bit of sp_recompile etc sprinkled here and there in maintenance plans that are run not too infrequently I would expect it to be controllable from the server side even with completely dynamic ad-hoc SQL queries…

I notice that you talked about our product, Visual NHibernate, and said “The tool isn’t always right so we have to go back and fix our mappings.”. If this is in regards to Visual NHibernate then please let us know what the problems are so that we can fix them ASAP. We are trying to bring the fun back into this area of software development – thanks for helping us!

All ORMs strive to get a good compromise, although I grant you that most of them tend to be a little more complicated than what is needed. An ORM is a shift of complexity from DB to application language, although the details make up for the additional complexity.
Let’s take Hibernate mappings: they’re a pain, but you can say that its

Even when you speak of OODBs such as db4o, its just another complexity shift from the SQL engine to the db4o storage engine.

The bottom line is: if you think an ORM is a panacea, you’re still in the last century. I though by know everyone should know that an abstraction layer doesn’t solve all your problems. Besides, it also depends on how you use the DB (see Martin Fowler’s application database vs. integration database). For integration databases, it makes sense to shift some of the logic to the DB, although you can still use an ORM.

Yes, on the big x64 servers with lots of memory the procedure cache can get very large, but that’s not a good thing. The larger the procedure cache is, the less memory there is for caching data, which means that SQL goes to disk more often, making that limited I/O bandwidth more of a bottleneck than it should be.