Many commentators seem to be getting hung up on "stored procedures." That's understandable given the title of the original post, but it's also unfortunate beca

Many commentators seem to be getting hung up on "stored procedures." That's understandable given the title of the original post, but it's also unfortunate because it mixes independent concerns: business-logic in the database, and using stored procedures. You can do the former without the latter, and in my experience it works better: * custom data types and domains * use schema and namespaces * foreign key constraints * check constraints * default values * views * functions (not stored procedures) * triggers In my experience, you can get a clean, efficient, easily-understood data model and application with those ingredients, without ever having to touch a stored procedure, a looping construct, or a conditional statement.