Stored Procedures as Primitive Services
time to read 2 min | 288 words

I got a couple of good comments on my previous post about stored procedures. I replied in the thread, so you can check it there.

This post is about abstracting the database so you can safely change it and using the same database from multiply applications. I would agree that you can use a layer of stored procedures to provide those capabilities, although I don't think in a really easy fashion. But can some one explain me the architecture differences between the following scenarios?

ֲ·         Web service as a repository for the data, talking to a database using the "I don't care" method. Users talks to the web service only.

ֲ·         Database exposes a set of stored procedures that the users are calling.

ֲ·         Especially since the second scenario often really looks like this:

 

If we ignore the implementation details, Stored Procedures are really the services that the database has to offer. They even have many of the same properties that the usual web services have (security, transactions, abstractions, etc). If I wanted to build a database for more than a single application, why would I tie myself to the database layer? Scaling the database is decidedly more difficult than scaling a web server.

Tweet Share Share 0 comments