在许多情况下，您可能需要集成多个数据库。这可能是特定应用程序项目所必需的。提供更加集中和高效的信息访问本身也是一个目标。
然而，实现这一点可能是一个挑战，尤其是对缺乏经验的开发人员来说。
今天，我们将研究两种方法—集成数据库的关键方法，以及Budibase如何让生活更轻松。
不过，首先，我们将从基础知识开始。
什么是数据库集成？
数据库集成意味着从多个不同的源获取数据，并创建一个可在整个组织中共享和管理的权威版本。这可以包括现有数据库，以及其他来源，如web服务或其他输入。
通常，这意味着将多个现有数据库合并为一个单一的统一资源。其他时候，这可能意味着保留单独的数据库，并创建一个查看、访问和管理信息的平台。
稍后我们将更详细地研究这些问题。
在这两种情况下，目标都是提高整个组织的信息共享、效率和决策能力。集成还有助于保护数据的有效性、完整性和安全性，以及基于此的任何工具的性能。
为什么要集成多个数据库？
现代企业收集和存储大量数据。集成在帮助您使用这些信息方面发挥着至关重要的作用，而不是被它淹没。
当你创造了一个真实的来源时，你就可以让你的团队做出更快、更好的决定。这也消除了在多个位置存储类似信息的需要，从而避免了重复和不一致问题。
此外，集成可用于提供更方便的数据管理过程。例如，通过使您的团队能够从一个工具在多个数据库上执行管理任务。
整合数据库还可以提高性能。例如，通过允许您通过查询单个集中数据库来访问相同的信息。
除此之外，在某些情况下，集成多个数据库是不可避免的。也就是说，这可能是应用程序满足其功能要求的要求。
考虑到这一点，让我们看看在实践中集成数据库的一些不同方法。
整合数据 vs 连接到多个数据库
如前所述，我们将研究两种不同的集成数据库的方法。每个都有自己的优点和缺点。一些应用程序项目将更适合其中之一。
第一个选项是将数据库整合到单个源中。即，获取现有数据，并将其迁移到单个新数据库。您可能需要这样做的原因有很多，例如，当将数据集移动到云时。
事实上，这种迁移通常是指数据库集成，尽管它不是唯一的方法。
当然，这里也有缺点。
首先，迁移总是会带来风险，包括服务中断、数据丢失或损坏。至少可以说，缓解这些问题是一项艰巨的任务。在某些情况下，这根本不值得，特别是对于小型内部工具。
在其他情况下，迁移根本不可行。
您经常受到软件堆栈中其他平台需求的限制。
例如，您可能需要从使用自己内部数据库的CRM工具中集成数据。如果一个工具会破坏您需要的其他平台，那么迁移数据来构建一个工具是没有意义的。
那么，如何在不进行大规模迁移的情况下集成多个数据源？
解决方案是创建专用工具来管理来自不同来源的数据。换句话说，创建接口、定义业务流程或创建虚拟表以实现无缝数据集成。
这里的目标是能够无缝地查询不同的数据库，就像它们是一个数据库一样。其中一个要素是保持存储在多个数据库中的类似属性之间的一致性。
例如，CRM和发票平台都存储客户的联系信息。
您可以将其视为一种事实上的集成，因为实际的数据库彼此保持独立和不同。
考虑到这一点，让我们深入探讨每种集成方法的实用性。
整合多个数据库
如前所述，集成通常是指将多个数据库合并到一个源中的做法。
然而，这在实践中可能意味着许多不同的事情。首先，这在很大程度上与所讨论的数据库的不同有关。
让我们来看看几个不同的场景，以及它们的区别。
将数据库与单个模式集成
如果您在不同的位置有多个数据库，但它们共享一个模式，那么整合相对简单。例如，如果不同的用户都具有相同数据集的本地版本。
查看我们关于数据库模式的文章以了解更多信息。
本质上，在这种情况下，我们需要做的就是创建一个与现有模式匹配的主数据库，并从本地版本导入所有值。
根据您用于新数据库的DBMS，这可以通过直接文件上载、自动查询甚至手动数据输入来完成。您选择哪种方法在很大程度上取决于您使用的数据集的规模和复杂性。
例如，如果您有由一个或两个表组成的多个数据库，那么手动上载数据可能是最简单的选择。使用Budibase，您可以使用CSV文件将数据批量导入我们的内部数据库或任何其他连接的源。
举一个简单的例子，假设您的每个销售团队都将他们的销售线索存储在各自的Postgres数据库中。每个人只有一张桌子。您决定将它们以MySQL表的形式集成到一个新的主列表中。
您的目标是构建一个应用程序，帮助销售同事共享信息，避免反复联系同一位同事。
我们可以在Budibase中将每个Postgres数据库添加为单独的数据源，自动获取表，并将所有值导出到CSV文件，而无需编写单个查询。然后，我们可以连接到新的MySQL表，并在Budibase生成器中导入值。
这会将所有现有值移动到主列表中。然后，我们可以创建一个简单的自动化，这样，每当单个销售同事添加新潜在客户时，它也会添加到主列表中。
从不同的数据库模式集成数据
自然，当您使用多个不共享公共模式的数据库时，事情会变得更加复杂。例如，如果要将多个完全不同的数据集移动到单个主源中。
在很大程度上，这有时也称为数据仓库。
事实上，这本身就是一门高度专业化的学科，因此建议我们可以在本指南中全面概述如何开展这项工作是有误导性的。
相反，让我们探讨在进行这种集成时必须记住的一些关键考虑因素。
评估您对新数据库的需求
您将在这里做出的许多决定将取决于存储实体之间的相似性或差异程度。这在创建新数据库模式时尤为重要。
因此，您可能有多个数据库存储关于同一实体的不同类型的信息。或者，您可能有几个处理完全不同的实体集的数据库。
例如，集成与客户相关的两组数据可能比集成两个完全不同的数据集要小得多。
在第一个场景中，我们只需要从DBMS中查询每个现有数据库，并为所需的每个实体创建新的主版本。
正如我们稍后将看到的，这在实践中可能会稍微复杂一些。
无论哪种情况，关键都是为主数据库定义一个满足信息需求的模式，同时保留原始源的内容。
保持一致性和完整性
在集成数据库时保持一致性和完整性可能是一项重大挑战。其中一部分与现有数据的类型和格式有关。当不同的数据库已经以不同的方式存储相似的属性时，这是一个特别值得关注的问题。
这可能源于原始数据库所有者做出的决定，或者源于底层DBMS的约定。
例如，不同的数据库可能会以不同的方式处理字符串或数字数据。这将在尝试操作值时造成困难。
这里的关键是有效地转换现有数据以满足新的数据库模式。这里的细节将因项目而异。查看我们的应用程序数据源终极指南，了解有关转换的更多信息。
处理重复和差异
数据库之间的重复值和差异是集成过程中的另一个主要问题。这里，重复意味着相同的值存储两次。当给定对象的相同属性存储两次，但值不同时，就会出现差异。
假设您正在集成两个数据库，每个数据库存储客户电话号码的值。如果在多个数据库中的不同表上保留此属性，则会发生重复。
如果您为同一客户存储了不同的电话号码，则会出现差异。这可以是值本身的级别，也可以是它的格式。
当然，在某些情况下，您可能希望在数据模型中构建冗余，但在单个数据库中实现这一点并不常见。
在集成项目中，这意味着您需要决定对任何重复属性优先考虑哪个源。
管理关系
当您为新的主数据库开发模式时，您可能必须彻底重新考虑不同实体之间的关系。这同样适用，无论您的原始数据库是否处理类似的实体。
在其他情况下，事情可能会简单一点。一些集成项目可能意味着将一个单独的附加表附加到一个更大的数据库中，并将其存储在一个新的模型和模式中。
这将相对简单，因为您可能不需要实质性地改变大多数实体的关系。
在其他情况下，定义实体之间的关系将更加复杂。我们已经创建了一个关于如何创建数据模型的专门指南，您可以查看该指南以了解更多信息。
存储、托管和访问
还有一个问题是如何物理存储和托管新数据库。例如，在云主机或本地存储之间进行选择。
您还需要考虑用于管理迁移数据的实际DMBS。
例如，我们前面提到了一个场景，我们可以将两个Postgres数据库集成到一个MySQL实例中。
显然，您将在这里做出的具体选择高度依赖于特定项目的需求。例如，您可能会选择Postgres、MySQL、MSSQL、SQL Server、Airtable、CouchDB、MongoDB、Oracle、S3或大量其他数据库工具。
移植风险
对于大型数据库整合项目，减轻不同的迁移风险也至关重要。
事实上，任何类型的数据迁移都有无数巨大的风险。
其中最明显的是数据丢失、损坏和服务中断时间延长。因此，彻底审查您在迁移过程中使用的任何集成工具和合作伙伴非常重要。
除此之外，大型集成项目还会对更广泛的软件堆栈产生影响。更具体地说，不同的工具在数据移动后查询数据时可能会遇到问题。它们也可能不支持新的数据存储或DBMS。
例如，当属性名称更改时，可能会出现语义问题，但自动查询没有更新以反映这一点。
如何在web应用程序中集成来自不同来源的数据
如前所述，存在批发整合的替代方案。这包括从一个工具查询多个数据源，实现集成的许多好处，而无需迁移数据。
这是跨不同数据集创建单一、可访问的真实来源的有效方法。我们还可以使用简单的web应用程序，通过定义的工作流提高效率并减轻管理多个数据库的管理负担。
这也消除了与其他类型集成相关的一些风险。
然而，在一个应用程序中使用多个数据库也会带来严重的挑战。例如，查询错误、源之间的不一致性，以及使用单个数据源的所有常见挑战。
因此，这种策略通常更适合于相对简单的工具和数据集。
本质上，这样的网络应用程序必须实现两件事：
- 为用户提供与查询单个主数据库相同的体验。
- 当通过其他现有工具进行更改时，保持连接数据库之间的一致性。
例如，您可能有单独的平台，内部数据库存储不同类型的客户信息。您可以构建一个工具，为您的服务团队提供单一的真实来源，并使其更易于管理和维护客户详细信息。
让我们看看你如何在Budibase建造这座建筑。
1.连接数据
第一步是将数据库连接到Budibase生成器。当然，您可能有几个数据源，但为了简单起见，我们将在示例中使用两个。假设我们有一个来自CRM的MySQL数据库和一个来自开票工具的Postgres数据库。
每个都有多个表，其中一个用于客户详细信息。这些通用表存储了一系列不同的属性，但每个数据库都包含每个客户的联系信息字段。
我们希望构建一个工具，内部用户和客户自己可以通过一个界面在两个数据库中更新他们的联系信息。
Budibase为外部数据提供了一系列直观的连接器。在生成器中，转到“数据”选项卡，然后选择加号图标以添加新源：
首先，我们将通过选择Postgres并输入凭据，连接到发票平台的数据库：
然后，我们可以对CRM的MySQL数据库执行同样的操作：
当我们保存其中的每一个并获取表时，我们将拥有在两个数据库上执行CRUD查询的完整连接。
每个数据库有两个表。我们的CRM为客户和用户存储实体：
开票工具为客户和发票提供了单独的表格：
在我们的示例中，我们只关注每个数据库中的customers表。我们可以单独处理这些表和其他内部表之间的关系。
2.创建组合数据表
请记住，我们的数据库共享每个客户的某些属性，但它们也存储一些独特的信息。具体来说，每个存储联系人详细信息以及其他独特属性。
我们的下一个任务是为用户提供一个单独的资源，在那里他们可以看到每个客户存储的所有详细信息。
换句话说，我们需要创建一个表，其中包含两个数据库的客户记录中的所有属性。我们可以用几种不同的方式来实现这一点，例如创建一个虚拟表。
出于我们的目的，我们将创建一个新的物理表。我们可以在现有数据库中使用BudibaseDB或在一个全新的数据库中执行此操作。为了简单起见，我们将在CRM的现有MySQL主机中创建一个新表。
我们将首先编写一个查询来复制CRM的客户表：
您可以在DMBS中执行此操作，也可以在Budibase中作为自定义查询执行，如上所示。
然后，我们可以使用Budibase将发票工具中所需的任何其他属性添加到新的组合表中。在我们的案例中，我们只有一个-客户的计费周期。
然后，我们将构建一个简单的自动化，将相关的计费周期值添加到新表中。有许多不同的方式可以触发此操作，包括用户操作或设置时间段。
然而，由于我们在发票客户数据集中只有相对较少的条目，我们将使用更新的行触发器，因此我们可以逐个传递每个值。
稍后我们将介绍更多的自动化。目前，我们所需要做的就是将初始值设置到位。首先，我们将在更新crm_business_information表中的行时设置触发器。
接下来，我们需要查询invoice_customers_table，并使用过滤器查找与触发器具有相同业务名称的行。
最后，我们将使用触发器行和invoice_customers表中的值的组合来更新combined_customers_table中的相关行。
有了这一点，我们就可以手动更新crm_business_infromation表中的任何行，以从发票数据库中携带账单周期值。
如果我们想批量执行此操作，我们可以使用不同的触发器（如用户操作），并更改自动化以遍历两个表中的每一行，并将新值添加到正确的行。
3.构建CRUD屏幕
现在我们有了一个组合表，我们可以开始构建CRUD屏幕来查询我们的两个数据库。记住，我们的目标是拥有一个用于管理两个数据库共享属性的单一接口。
因此，基本上，我们需要创建一个表单，在那里我们可以编辑客户的联系信息，并将这些新信息传递给我们的CRM和发票平台。
显然，最好的用户体验是允许用户通过一个表单完成这一操作。
我们希望这可以更新客户的联系信息，同时将任何唯一属性单独保留在任一数据库中。
首先，我们将自动为组合的customers__table生成CRUD屏幕。
为了简单起见，我们将通过将编辑表单UI设置为以模态打开，使其成为一个单屏幕应用程序。当您在Budibase中自动生成CRUD屏幕时，您还可以创建行表单，但我们不需要这些表单。
现在，我们将开始处理编辑表单。
我们需要做的第一件事是删除不希望用户通过表单编辑的属性的任何字段。因此，在本例中，非接触式详细信息是ID、类别、描述和billing_cycle。
我们现在有了一个工作表单。但是，如果用户完成了这一操作，它只会更改组合表中的条目详细信息，而不会更改两个源表。
接下来，我们需要创建自动操作，以在合并表中的行发生更改时更新源数据库。
4.自动查询
记得前面我们创建了一个自动化，这样当crm_business_information表中的一行被更新时，invoice_customers中的相关客户将被查询，而他们的详细信息将在combined_customers_table中更新。
我们的应用程序要求如下：
- 用户可以使用单个表单界面更新两个源数据库中的客户联系信息。
- 当手动更新其中一个源数据库时，另一个数据库中的联系人详细信息应保持最新。
因此，我们实际上需要三种类似的自动化：
- 表单完成后，两个源数据库都会更新新的联系人详细信息。
- 在外部更新crm_business_information表时，应更新组合列表和invoice_customers表以反映这一点。
- 如果invoice_customers表已更新，则组合列表和crm_business_information也应如此。
首先，我们将在用户完成表单时更新源数据库。因此，我们将再次使用更新的行触发器。然后，我们希望遵循与前面相同的步骤。因此，对于每个源数据库，我们将执行以下操作：
添加一个查询行块，并设置一个过滤器以隔离与触发器具有相同业务名称的行。
添加一个更新行块，使用我们的表单数据更新联系人详细信息。
我们使用查询行块输出的ID和原始表单触发器提供的信息来更新相关行：
我们使用JavaScript绑定将每个单独的属性传递给我们的自动化：
现在，我们可以通过为invoice_customers表添加相同的块来重复这个过程。
我们可以测试我们的自动化，以确保它在现实生活中工作。我们将使用我们的表单将一个客户的电话号码更新为000-000-000：
然后，我们将在源DMBS中运行查询，以确保其正常工作。MySQL数据库中的第一个
然后在我们的Postgres表中：
现在，我们可以使用一个表单UI在多个数据库中更新客户的联系信息。
最后一步是创建自动化流程，以便每当在各自的外部平台中更新其中一个数据库时，这一变化都会反映在另一个数据库中。
对于大部分自动化，我们可以使用与上述完全相同的步骤。我们只需要为每个表组合修改它。
我们可以通过几种不同的方式来触发这一点。
一种选择是，当出现差异时，决定我们的哪个表优先。然后，我们可以使用按时间顺序的触发器周期性地遍历两个表中的每一行，并相应地更新它们。
或者，当任何数据库发生更改时，我们可以使用更新行触发器来自动更新所有相关条目，这与我们使用combind_customers_table中的触发器的方式大致相同。
如何确保来自多个源的数据兼容？
最后，请注意在集成多个数据库时保持一致。到目前为止，在我们的所有示例中，我们都使用了具有相对基本模式的小型数据集。当然，情况并不总是这样。
实际上，在许多情况下，不同数据库中类似属性的值不兼容。
在这些情况下，您需要使用转换来确保数据兼容。
例如，如果我们的一个现有数据源将某个特定属性存储为字符串，而另一个数据源将数值存储为同一变量，则需要执行此操作。这可能发生在不同平台上的客户电话号码上。
我们不一定要改变现有数据库的模式。毕竟，我们可能有其他工具依赖这些数据，我们不想打破这些。相反，我们可以在数据库之间传递值时使用JavaScipt表达式来转换值。
在Budibase中，您可以创建自定义查询来执行转换，也可以在创建自动化时绑定任何值时使用自定义JavaScript。
查看我们的web应用程序数据源终极指南，了解有关转换的更多信息，以及如何在使用多个数据库时使用这些数据源。
