Web服务和数据库如何相互关联？

Question

Web服务是一小部分功能或数据捆绑在一起并封装为小型独立实体的想法非常清楚，并且很有意义。但是，服务如何与他们使用的数据库相关或为其提供接口？

例如，当从一个单层的2层架构迁移到一个处理所有内容的大型数据库到基于服务的架构时，数据库如何受到影响？数据库是否被分成较小的数据库，每个数据库是通过服务连接的，还是每个服务只是与原始的海量数据库进行交互？

此外，如果数据库分为例如用于用户身份验证的服务和用于产品信息的服务，那么跟踪原始海量数据库中每个用户的产品视图的多对多实体最终会在哪里？< / p>

Answer 1

简单地说，“没关系”。

任何适合你的人。

在服务API级别，数据库“不存在”，它只是一个实现细节。

如果API正确完成，数据库的实现不应该将API层“渗透”到客户端。

在API级别完成后，您可以选择“按原样”保留数据库（如果它正常，执行，维护等），或者您可以立即开始将它们全部分开，或逐步地。

显然，打破数据库会有自己的挑战和问题。

所以，我从服务及其API开始，确保您和您的客户对这些服务感到满意。仅此过程可能会让您做出决定。

Answer 2

我认为Martin Fowler在他的Database Thaw文章中对这个主题有一个有趣的看法（我会说必读！）：

  

如果您切换集成   从SQL到HTTP的协议，现在   意味着您可以从中更改数据库   是IntegrationDatabases到   ApplicationDatabases。这种变化是   深刻。 ......如果你整合了   HTTP不再重要   应用程序存储自己的数据，其中   反过来意味着应用程序可以   选择一个有意义的数据模型   为了自己的需要。

因此，从“数据库到WS”的切换可以让您更加关注数据。没有必要首先定制所有内容以适应关系模型，但您可以使用其他模型，如键/值存储，图形数据库或面向文档的方法。 - 无论什么是最适合手头的域名。在许多情况下，它当然可以是不同模型的组合。

Answer 3

我认为Will Hartung的答案几乎是完美的，但我会包括ETL（提取，转换和加载）的特殊情况。

此集成模式有时在WS的上下文中使用，并涉及WS调用（有时由企业服务总线（ESB）路由或编排），以直接从数据库中提取数据。