-
Security. You’re not granting DB access to anyone but web server/app user.
This is extra important when you have tons of users. You avoid the pain of user/role maintenance on DB side.
-
DB load reduction. Web service can cache the data it retrieved from DB.
-
Database connection pooling (hat/tip @Dogs).
A web service can use a small pool of permanently opened DB connections. The helps in a variety of ways:
-
DB connection pool is limited on database server side.
-
opening a new DB connection is VERY costly (especially to database server).
-
-
Ability for fault tolerance – the service can switch between primary/DR data sources without having details of fail-over be implemented by service consumers.
-
Scalability – the service can spread requests between several parallel data sources without having details of the resource picking be implemented by service consumers.
-
Encapsulation. You can change underlying DB implementation without impacting service users.
-
Data enrichment (this includes anything from client customization to localization to internalization). Basically any of these might be useful but any of them is a major load on database and often very hard to implement inside a DB.
-
May or may not apply to you – certain architecture decisions are not DB acces friendly.
E.g. Java Servers running on Unix have an easy access to a database, whereas a java client running on a Windows PC is not database aware nor do you possibly want it to be. -
Portability. Your clients may not all be on the same platform/architecture/language. Re-creating a good data access layer in each one of those is harder (since it must take into account such issues as above-mentioned failovers/etc…) than building a consumer layer for a web service.
-
Performance tuning. Assuming the alternative is clients running their own queries (and not pre-canned stored procedures), you can be 100% sure that they will start using less than optimal queries. Also, if the web service bounds the set of allowable queries, it can help with your database tuning significantly. I must add that this logic is equally applicable to stored procedures, not unique to web services.
A good list can also be found on this page: ‘Encapsulating Database Access: An Agile “Best” Practice’
Just to be crystal clear – some of these issues may not be applicable to ALL situations. Some people don’t care about portability. Some people don’t need to worry about DB security. Some people don’t need to worry about DB scalability.