direct access database vs web service [closed]

Question

What are the pros and the cons when we have the choice between using direct database access or using web services?

What would be your choice for a critical application that should be responsive (<0.5 sec) and with a low call to this webservice/DB (NB: the web service will be maintained by another team).

Answer 1

Direct database access couples you tightly to the schema. Any changes on either end affects the other. But it's got the virtues of being simple and requiring one less network hop.

A web service means better abstraction and looser coupling via one additional level of indirection. A web service can act as the single steward of the data. You'll get away with going directly against the database when it's just your app, but if other apps come along and require the same data you'll increase the chances that they'll need schema changes some day. Those changes will affect your app as well. The cost is more latency.

A web service can be a good place to centralize authorization and security. A database can do this as well, so perhaps it's a wash.

Answer 2

Obviously, a direct database access will always be faster in simple scenarios.

With a WebService, you gain flexibility :

• plug-in a different implementation,
• when several applications need access to the same data, make one responsible for that data, and have the other one access it through a WebService : you will have no data lag between the two ; and you can keep often-accessed data in memory in that application, instead of using the database to communicate between applications....

Given your context of responsiveness (with possibly a problem with the other team), I would try to go the direct database access route, unless several applications need to share the data...