The funny thing is that there was a time (at least with Microsoft) where you were supposedly doing it totally wrong if you didn't use stored procedures enough.

The funny thing is that there was a time (at least with Microsoft) where you were supposedly doing it totally wrong if you didn't use stored procedures enough. And I swear there was a time when every web developer knew that if you wanted a consistent, reliable layout for a home page, you sliced the design up into a table, and stayed away from that new CSS stuff because it was buggy and incompatible with different browsers. The reality is that there are several very different general approaches that can work for any particular information system. Some of them will be more compatible with each other or with certain tools. But I think that for the vast majority of applications, this comes down to trends more than any particular technical issue. I mean, technically speaking there are an effectively infinite number of ways to organize and distribute the code and data that will given the same outputs from given inputs. People use "best practices" as a shortcut to make it easier to judge things or decide how to approach a problem. I think one mark of a good engineer is their ability to adapt to different approaches. This actually requires more intelligence or at least energy because it means they might need to actually read code to decide if the approach makes sense. But it will save people quite a lot of energy to simply say "we [always/never] use stored procedures here!" And also even for brilliant engineers, constantly trying to wrap your head around completely different approaches can be impractical. So programming communities adopt their own worldviews. For the most part, it just means that you spend slightly more time on certain types of problems than the other group. But that group may not realize they are spending time on another thing. So there are trade-offs with every approach. Which is not to say that some frameworks can't save you more time than others. One aspect of this is compatibility. The whole approach may get thrown off if you use stored procedures versus not, depending on the rest of the framework. But I would suggest that there is usually just as much cultural preference as actual technical merit to these debates when you dig deep into the details.