Closed. This question is opinion-based 。它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文来回答。
4年前关闭。
Improve this question
Web 服务是捆绑在一起并封装为小的独立实体的一小部分功能或数据的想法非常清楚，并且很有意义。但是服务如何与它们使用或为其提供接口(interface)的数据库相关联？
例如，当从具有处理所有内容的大型数据库的单体式 2 层架构转变为基于服务的架构时，数据库会受到怎样的影响？是将数据库分成更小的数据库，每个数据库都通过一个服务进行交互，还是每个服务都只是与原始的海量数据库交互？
此外，如果将数据库分为例如用于用户身份验证的服务和用于产品信息的服务，那么在原始海量数据库中跟踪每个用户的产品 View 的多对多实体将在哪里结束？
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文来回答。
4年前关闭。
Improve this question
Web 服务是捆绑在一起并封装为小的独立实体的一小部分功能或数据的想法非常清楚，并且很有意义。但是服务如何与它们使用或为其提供接口(interface)的数据库相关联？
例如，当从具有处理所有内容的大型数据库的单体式 2 层架构转变为基于服务的架构时，数据库会受到怎样的影响？是将数据库分成更小的数据库，每个数据库都通过一个服务进行交互，还是每个服务都只是与原始的海量数据库交互？
此外，如果将数据库分为例如用于用户身份验证的服务和用于产品信息的服务，那么在原始海量数据库中跟踪每个用户的产品 View 的多对多实体将在哪里结束？
最佳答案
简单地说，“没关系”。
做适合你的。
在服务 API 级别，数据库“不存在”，它只是一个实现细节。
如果 API 做得好，数据库的实现不应该“渗透”API 层到客户端。
在 API 级别完成此操作后，您可以选择“按原样”保留数据库(如果它具有功能性、执行性、可维护性等)，或者您可以开始一次性或逐步将其全部分解。
显然，拆分数据库将面临其自身的挑战和问题。
因此，我将从服务及其 API 开始，并确保您和您的客户对这些感到满意。仅此过程就可以为您做出决定。