direct access database vs web service [closed]

Answer 1

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...

Answer 2

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 3

Both Duffymo and KLE make valid points.

An additional consideration is the degree of coupling to other teams.

When working with a service layer, your project is usually one of many clients; this often means that you either have to work with the services that are available, or wait for the roadmap to deliver the changes you might need. This often leads to decisions that are good for the enterprise as a whole, but not so good for your project.