Thoughtstack
The first time I found the web was in 1995 and I spent about 4 hours surfing that first night, just finding cool stuff because someone else had linked to it. I had one of those moments this morning, reading Sam Ruby's reaction to Dare Obasanjo's reaction to CouchDB. Sam's article led me to Choose a single layer of cleverness, which led me to Should Database Manage the Meaning?. There's a lot in there. I have a number of thoughts on the matter of stored procedures, since I do a lot of programming against SQL Server, and stored procs are practically gospel. Even though 21st century versions of SQL Server can cache query plans to bring ad-hoc queries up to par performance-wise with stored procs, people in the MS world live and die by stored procedures. So I've struggled a great deal with the idea of pushing business logic onto the DB. It mostly boils down to optimization. On the one hand, you can come up with a highly optimized query that might otherwise require several queries. Relational DBs are really good at managing relational data, so often that work is best pushed to the DB. On the other hand, pushing that logic to the DB makes understanding your application more difficult because you sometimes end up with logic strewn all over the place, and often you start to approach the DBMS as an RPC server and sometimes people forget that RPC costs something, and now you're making several remote calls to the DB to do logic, which is certainly not optimal. For some reason, I'm remembering a stored proc I used to know named something like GetUserID, which somewhat surprisingly would create a new row if the name supplied didn't exist. I've always regarded that as a particular case of pure DBMS evil.
Someday, I'll get around to looking at CouchDB, after I unwind the stack on all these other thoughts.
— Gordon Weakliem at permanent link
Backing Up
Reading over Dare's comments on CouchDB, I'm directed at Pat Helland's Memories, Guesses, and Apolgies, where Dare quotes "Business realities force apologies". I thought that "Decisions made by the computer may not be possible to implement", but it's the same thing in the end. My first job out of high school was working in a warehouse. You'd think that it would be straightforward, managing inventory. You take a certain amount of stuff in through the receiving dock. You ship a certain amount out via the shipping dock. Yet in annual inventory, our actual counts came up wildly off.
Dare also refers to CouchDB: Thinking Beyond the RDBMS, specifically referring to the line "Features like referential integrity, constraints and atomic updates are really important in the client-server world, but irrelevant in a world of services." This line is a bit fuzzy, particularly in the bogus distinction between client-server and services. You mean we go on the Internet and don't care about data integrity? The practical reality is that relational integrity is expensive, and as an optimization, we remove some of those constraints. This is where a good DBA earns his money. If you write to an index 30,000 times a day, and never once read the index, why do you maintain the index. Databases, like programs, need to be profiled and tuned.
All this circles around to the question of whether a relational DB is worth the pain. A DBMS imposes a certain overhead in operations, programming, and certainly in hardware and possibly license costs. Yet we somewhat hastily conclude that a relational DBMS is a necessity for a serious application.