Web 服务是捆绑在一起并封装为小的独立实体的一小部分功能或数据，这一想法非常明确，也很有意义。但是服务如何与它们使用或提供接口的数据库相关联？
例如，当从具有处理所有事情的大型数据库的单片 2 层架构迁移到基于服务的架构时，数据库会受到怎样的影响？数据库是分块成更小的数据库，每个数据库都通过一个服务进行交互，还是每个服务都只是与原始海量数据库交互？
此外，如果数据库被拆分为，例如，用于用户身份验证的服务和用于产品信息的服务，那么在原始海量数据库中跟踪每个用户的产品浏览量的多对多实体将在哪里结束？
【问题讨论】：
标签： database web-services database-design architecture
简单地说，“没关系”。
做任何适合你的。
在服务 API 级别，数据库“不存在”，它只是一个实现细节。
如果 API 正确完成，数据库的实现不应“渗透”到客户端的 API 层。
在 API 级别完成此操作后，您可以选择让数据库保持“原样”（如果它可以正常工作、执行、可维护等），或者您可以立即开始将其全部分解，或增量。
显然，拆分 DB 将有其自身的挑战和问题。
所以，我将从服务及其 API 开始，并确保您和您的客户对这些感到满意。仅此过程可能会为您做出决定。
【讨论】：
我认为 Martin Fowler 在他的 Database Thaw 文章中对这个主题有一个有趣的看法（我想说的是必读！）：
如果您切换集成 从 SQL 到 HTTP 的协议，现在 意味着您可以从 作为集成数据库 应用程序数据库。这种变化是 深刻的。 ...如果你通过整合 HTTP 不再重要 应用程序存储自己的数据，其中 反过来意味着应用程序可以 选择有意义的数据模型 满足自己的需要。
所以“从 DB 到 WS”的切换会让您更关心您的数据。无需首先调整所有内容以适应关系模型，但您可以使用其他模型以及键/值存储、图形数据库或面向文档的方法。 - 任何最适合手头领域的东西。在许多情况下，它当然可以是不同模型的组合。
【讨论】：
我认为 Will Hartung 的答案几乎是完美的，但我会包括 ETL（提取、转换和加载）的特殊情况。
这种集成模式有时用于 WS 的上下文中，并涉及 WS 调用（有时由企业服务总线 (ESB) 路由或编排），以直接从数据库中提取数据。
【讨论】：