Good case of avoiding early optimization but hard to believe in 2005 someone thought it was a good idea to build your business rules in your database layer.
I don't find it to be all that surprising. I remember when Ruby on Rails was just starting to gain in popularity around the same timeframe. One of the big arguments against it was that it pushed you to put all of your business logic in the application. "How will you write another application to use the same database?" they would cry.
The answer turned out to be write one application tier that provides a web API to the database for all other applications to use. Interestingly, that turned out to be a pretty popular solution and is now probably the most prevailing method to get data to your user-facing applications. Looking back, it seems pretty obvious especially with the rise of mobile apps using that technology. It wasn't clear to most people in 2005, however.
This seems like an ongoing debate, I remember similar discussions between Java developers and DBAs before the rise of RoR. The answer back then was to migrate business logic into business logic servers, with application servers talking to the business logic serves over a queue. Architectures like that allow organizations to have heterogenous application architectures: One company had .NET for internal apps and Java for customer-facing web systems.
Everything talked happily to a business logic server written in Java, and that server talked to a couple of different databases and some legacy systems, one of which was written in MUMPs.
In fact, I'm working on a Rails app right now facing this choice. We're a small site, barely a thousand users, but we have some complex queries for relevancy ranking that are just too slow in ActiveRecord - it ends up creating lots of expensive objects which kill you on GC. Whether this code turns into a SQL-based view or a full-on PL/pgSQL procedure is largely dependent on my mood tomorrow morning, but the fact remains that ActiveRecord can't solve all your problems. In fact, putting this logic in the database will help us make other application logic cleaner and more ActiveRecord-y; all of a sudden, we'll be able to do Content.order(:relevance).paginate, instead of having to pass around unwieldy arrays of content.
Many Postgres folks seem to think putting you rules in your database layer is a good idea, because you (1) get to deploy them automagically, (2) the commit logic is easier when there is no round trip, and (3) the PL/PGSQL language is actually pretty good.
I don't work on things big enough to think about this, and I would be curious if there were a summary of why/ why-not to put business logic in the DB, and where it SHOULD go.
but hard to believe in 2005 someone thought it was a good idea to build your business rules in your database layer.
I remember having that exact argument in 2005. Someone not only thought it was a good idea, but thought it was a good enough idea to aggressively argue with me for.
This brought up some repressed memories. As part of the same argument, people were advocating for keeping executable code (VbScript) as well as HTML strings in the database layer.
The whole codebase was this Lovecraftian nightmare where I kept fearing I would go insane if I kept reading.
Don't ever get a job at a bank. It's all stored procedures with no mocked out unit tests. Like others below mentioned, it's the "Enterprise-y" way of doing things. Coding with GUIs.
I burned myself in that time frame, trying to implement SPs, because some people advocated for them.
Like Etsy, I discovered you needed a lot of them, and worse, they weren't very easy to debug or version control. I think I decided to pull them back into the application layer in the face of those problems, and I probably would have avoided the SP path entirely if I'd known about sharding back then.
