问大型科技公司如何跨多个团队共享数据库？

EN

在微服务体系结构中，每个微服务公开其他微服务可以在服务之间访问共享信息的端点。因此，一个服务将存储由另一个微服务管理的记录的最小信息。例如，如果用户服务希望在电子商务情况下获取特定用户的订单，那么订单服务将公开一个端点，因为用户id将返回与所提供的userid相关的所有订单，因此on...so本质上是订单服务需要存储的唯一与用户有关的字段，其余的用户详细信息与它无关。

为了进一步提高团队之间的凝聚力和理解，还构建了数据发现apis/文档，以便将数据库元数据共享给其他团队，以进一步解释每个表/字段对有效规划微服务的意义。您可以更多地了解这些公司如何构建数据发现工具这里。

如果我对你的理解是正确的，你不确定不同的部门如何在一家公司接收数据？

我们的想法是创建可重用和有效的API来解决这个问题。

让我们概括地说，我们正在调查的公司是沃尔玛。沃尔玛( Walmart )的数据库中有数百万件商品。每个项目都有一个唯一的ID等。

如果沃尔玛通过walmart.com在线销售商品，他们必须有办法获得这些商品，所以他们创建API，并根据特定的查询条件使用它们来抓取商品。

现在，假设沃尔玛已经决定开发一个应用程序..。他们需要同样的东西！好的，我们已经创建了那些API，我们将使用完全相同的API来获取数据。

现在，沃尔玛如何管理哪些商品在哪一家商店可以买到，以什么价格买到？它们通常通过附加的数据库模式表将这些元数据链接起来，并将它们与主键和外键绑定在一起。

^^这基本上允许沃尔玛只从其核心数据库中抓取项目，该数据库中只有项目所需的详细信息(例如名称、大小、颜色、SKU、details等)，并将其链接到另一个数据库，即本地沃尔玛，该数据库只包含与该商品相关的沃尔玛位置信息(例如价格、库存、走道号码等)。

所以从某种意义上说，使用多个数据库是的。

也许这会让你走更多的路：https://learnsql.com/blog/why-use-primary-key-foreign-key/ https://towardsdatascience.com/designing-a-relational-database-and-creating-an-entity-relationship-diagram-89c1c19320b2

在大型科技公司之间，甚至在大科技公司内部，使用的方法有很大的不同，它们受到不同的公司/组织文化以及围绕一致性和可用性的不同需求的驱动。

当您有一个显式的“查询另一个服务/另一个DB”依赖时，您就有了一个耦合，它倾向于将一个服务中的问题转化为两个服务中的一个问题(这并不一定是一个单向的事情:查询服务很有可能遇到一个问题，然后在查询的服务中出现问题(当缓存成为负载时，这是特别可能的，在不远的过去，这导致了至少一个大故障))。

这使得一些可能被称为“大科技”的公司在服务设计中避开了这种方法，通常是让服务发布事件来描述已更改为持久日志(仅附加存储)的内容。其他服务订阅该日志并使用事件来构建自己对其他服务拥有的数据的最终一致视图(即存在某种级别的数据复制，服务存储它们所需的数据)。