Re:Ask HN: Ridiculous Coding Practices by companies you have...
by jrockway on Thursday June 04, 2009 @05:25PM
(#642267)
Your point 2 is far from ridiculous. We do it that way so the business logic exists and is enforced in one place rather than being scattered around this desktop app and that website and so on. Only the most trivial applications can afford to put all their business logic in the middle tier.
But of course, the middle layer that applications talk to need not be the database. A simple RPC server between the apps and the database makes maintaining the system significantly easier. Your procedures are "normal code" that you already have a toolchain in place for dealing with. (Testing, libraries, version control, etc.)
The environment is richer, which means the middle tier can handle caching, sharding, replication, auditing, and anything else that you might need to add. And, you can add these things incrementally, without touching the apps that speak to this server.
IMHO, stored procedures are a quick hack that are barely viable for even the simplest tasks. Many people seem to disagree, but I doubt they have ever considered any other way.
(A notable example of this system is Flickr. Their internal apps, like the public web interface, use the Flickr API to do their work. In this case, the web app that powers the API is the "middle layer"/"RPC server". I think this worked out pretty well for them, and it made it easy to expose their database to third parties.)
But of course, the middle layer that applications talk to need not be the database. A simple RPC server between the apps and the database makes maintaining the system significantly easier. Your procedures are "normal code" that you already have a toolchain in place for dealing with. (Testing, libraries, version control, etc.)
The environment is richer, which means the middle tier can handle caching, sharding, replication, auditing, and anything else that you might need to add. And, you can add these things incrementally, without touching the apps that speak to this server.
IMHO, stored procedures are a quick hack that are barely viable for even the simplest tasks. Many people seem to disagree, but I doubt they have ever considered any other way.
(A notable example of this system is Flickr. Their internal apps, like the public web interface, use the Flickr API to do their work. In this case, the web app that powers the API is the "middle layer"/"RPC server". I think this worked out pretty well for them, and it made it easy to expose their database to third parties.)