The idea that web services are small bits of functionality or data that are bundled together and encapsulated as small, stand-alone entities is pretty clear, and makes good sense. But how do services relate to databases that they use or provide an interface for?
For example, when moving from a monolithic, 2-tier architecture with a massive database that handled everything to a services-based architecture, how is the database affected? Is the database chunked into smaller databases and each one interfaced with via a service, or does each service simply interact with the original massive database?
Also, if the database get’s split up into, say, a service for user authentication and one for product information, where would the many-to-many entity that tracked product views per user in the original massive database end up?
Simply put, ‘it doesn’t matter’.
Do whichever suits you.
At the Service API level, the DB ‘doesn’t exist’, and it’s simply an implementation detail.
If the API is done properly, the implementation of the database should not ‘seep through’ the API layer to the clients.
Once you’ve accomplished that at the API level, you can choose to leave the DB ‘as is’ (if it’s functional, performs, maintainable, etc.), or you can start breaking it all apart all at once, or incrementally.
Obviously, breaking the DB up is going to have its own challenges and issues.
So, I’d start with the services and their APIs, and making sure you and your clients are happy with those. That process alone may make your decision for you.