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

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

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

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

简单地说,"没关系".

做任何适合你的人.

在Service API级别,DB"不存在",它只是一个实现细节.

如果API正确完成,则数据库的实现不应该将API层"渗透"到客户端.

在API级别完成后,您可以选择"按原样"保留数据库(如果它是正常的,执行的,可维护的等),或者您可以一次性或逐步地将它们全部分开.

显然,打破DB会有自己的挑战和问题.

因此,我将从服务及其API开始,并确保您和您的客户对这些服务感到满意.仅此过程可能会让您做出决定.

我认为Martin Fowler在他的Database Thaw文章中对这个主题有一个有趣的看法(我会说必读!):

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

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