Web服务和数据库之间有什么关系？

Question

Web服务是将小的功能或数据捆绑在一起，封装为小型独立实体的理念非常清晰，而且很有道理。但是，服务如何与它们使用或提供接口的数据库相关联呢？

例如，从处理所有内容的大型数据库的单片式2层架构转移到基于服务的架构时，数据库会受到什么影响？数据库是否被分成较小的数据库，并通过服务与每个数据库进行交互，还是每个服务只是与原始的大型数据库进行交互？

此外，如果数据库被拆分成用于用户身份验证的服务和用于产品信息的服务，那么在原始的大型数据库中跟踪每个用户产品浏览量的多对多实体将会出现在哪里？

- cdeszaq

Answer 1

简单来说，“它并不重要”。

做适合你的事情。

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

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

一旦在API层面完成了这个目标，你可以选择将数据库保持“原样”（如果它的功能性、性能、可维护性等都很好），或者你可以开始一次性或逐步地将其全部拆分。

显然，拆分数据库会有其自身的挑战和问题。

因此，我建议从服务和它们的API入手，确保你和你的客户对它们满意。这一过程本身可能就能为你做出决策。

- Will Hartung

Answer 2

我认为马丁·福勒（Martin Fowler）在他的文章《Database Thaw》中对这个问题有一个很有趣的看法（我会说这是必读的！）：

如果你将你的集成协议从SQL切换到HTTP，那么现在你可以将数据库从IntegrationDatabases更改为ApplicationDatabases。这种变化是深刻的……如果你通过HTTP进行集成，那么应用程序存储自己数据的方式就不再重要，这反过来意味着应用程序可以选择符合其自身需求的数据模型。

因此，“从数据库到网络服务”的转变使您更加关注自己的数据。没有必要先把一切都适配关系模型，而是可以采用其他模型，比如键/值存储、图形数据库或面向文档的方法。- 无论哪种模型最适合当前领域。当然，在许多情况下，也可以使用不同模型的组合。

- nawroth

Answer 3

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

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

- Kaiser Advisor