Salesforce数据迁移的一个模式

就是今天。欢迎收看另一场专家数据峰会演讲。这是马丁·加德纳的作品。他的头衔是解决方案负责人。他在一家名为Slalom的国际咨询公司工作。他在这家咨询公司的Salesforce部门工作，但他们还有其他能力，他会告诉你的。

[00:00:32]他今天的演讲是关于数据迁移的模式。它更多的是关于数据迁移的所有事情。我看过了，我觉得它很有趣，也很重要。当人们只关注数据迁移的技术方面时，就会忽略这一点。

(00:00:49)言归正传，这是我们今天要学习的马丁。

[00:00:55]好的，非常感谢。是的。我的名字是Martin，今天我在这里[00:01:00]要谈谈我多年来开发的一种数据迁移模式。我是障碍滑雪的解决方案负责人。我们是一家大型咨询公司。我在Salesforce的伦敦办公室工作。我们还与AWS、Tablo和Snowflake合作，并拥有一个庞大的业务，我们自己从头开始构建东西。您可能已经意识到，如果您以前做过数据迁移，那么它们是相当困难的。它们不仅仅是一项技术练习。在进行数据迁移时，有很多事情需要考虑。

[00:01:39]本节课将讨论在构建数据迁移项目时需要记住或考虑的所有事项。那么我们怎么可能记住所有这些东西呢?如果我们把它们想象成金字塔，那就很好了。所以我们有[00:02:00]四个方面要研究。

[00:02:03]我们将拥有数据、方法、技术和人员。我将依次解决其中的每一个问题，并将其分解，向您展示每一个问题的含义，以及为了使数据迁移成功，您需要考虑、记住或采取什么行动。让我们看第一件事，数据。

[00:02:30]首先，我们如何保证我们在生产过程中使用的数据是高质量的?如果到达目标系统的数据完全被打乱或以任何方式被打乱，我们就不能说我们已经成功地迁移了数据。所以我们需要决定如何衡量这种质量。

[00:02:55]在[00:03:00]起始点时间迁移开始时，我们要制定什么样的规则或关键绩效指标，以便在数据进入时，我们能够了解数据的质量，然后在另一端，我们可以使用这些规则或kpi来验证我们没有把数据弄得更糟。

[00:03:17]在数据迁移中，清理数据是很有诱惑力的，当你把数据带过去的时候清理它，这有时涉及到合并记录。所以如果你在寻找duper切和合并它们，这是非常棘手的测试。所以如果你打算这么做，我建议你把它单独放到一个单独的项目或单独的阶段。

[00:03:41]因此，在尝试迁移之前要进行重复数据删除和合并，因为检查迁移是否正确的一个非常简单的方法是计算源中在目标中遇到的记录的数量。如果您在过程中合并了它们，那么您就不能依靠[00:04:00]来判断您是否有几条记录或几千条记录的错误。

[00:04:05]所以在数据迁移过程中，你真的需要小心处理这些数据质量问题。因此，我建议在流程的开始和结束处设置一些门，以确保数据的一定质量水平，然后将其作为衡量流程进展情况的手段。

[00:04:28]你可能会在源数据中发现一些你可能需要处理的事情，比如电子邮件地址、失败的长度、数据类型、带空值的强制字段和破坏的引用完整性。通过Salesforce到Salesforce的迁移，您可能会看到更少的主题和地址问题，因为Salesforce电子邮件字段已经有了一些验证，您不太可能发现参考完整性问题

[00:04:55]只要你在建立关系，使用查找和[00:05:00]掌握详细信息，而不是将id存储在文本字段或类似的东西中。然而，如果您从任何其他数据源、SQL服务器或管理程度较低的系统提取数据，那么您很可能会发现这些东西。所以你需要在源数据中寻找这些作为输入的一部分，

00:05:17 kpi。

[00:05:21]因此，当我们对质量有了一个概念后，我们要确保不让质量低劣的数据进入这个过程。因此，我们已经为输入划分了我们的角色，然后我们筛选出不符合这些规则的任何记录，并在它们通过流程之前将它们传递回客户端进行解决。

[00:05:43]通过这种方式，我们可以确保当我们进入目标系统时，那里的数据具有已知的质量水平，并且可以被UAT所接受。接下来是数据区域的位置。这是一个更实际的方面，比如，[00:06:00]数据在哪里?它是在云端，还是我们要把它存储在本地?

[00:06:04]当它被迁移时，它将被存储在哪里?它会被存储在内存中吗?他会被缓存到某个磁盘上吗?此外，它是否会跨越国际边界?那么，我们是将数据从中国转移到美国，还是从美国通过中国转移到欧洲?这些暗示是什么?

[00:06:30]我们是否需要考虑其中的法律影响?接下来是数据量。我们确实需要清楚地了解我们移动了多少数据以及我们需要以多快的速度移动它们。这意味着我们可以利用这些信息来确定我们是否要选择这些工具

[00:06:51]将能够支持你的数据。现在，如果我们在项目一开始就这么做，我们就可以根据我们正在移动的[00:07:00]数据量进行定制。我们还可以检查目标系统是否能够支持该数据量。在Salesforce的世界里，有几种不同的方式来管理大量的数据。

[00:07:13]因此，你可能需要考虑是否应该将数据迁移到Salesforce中，或者是否应该将数据迁移到一个更划算的数据存储中，然后使用外部对象访问数据，或者类似的事情。最后，也是在数据领域最重要的是安全性。

[00:07:34]因此，我们需要知道。数据会在哪里?谁在照看它?谁能拿到这些信息?我们要怎么控制它?GDPR或其他立法是否要求我们确保其安全?我建议在处理数据时确保客户保留[00:08:00]

[00:08:03]他们自己系统上的数据所以通常最好是建立客户端，建立一个虚拟机，然后我们在虚拟机上做工作在他们的控制范围内这样他们就不会把数据传递给我们来处理。这让事情变得简单而美好。所以我们在这里。

[00:08:23]这些是这方面的小贴士。我们希望为进入迁移管道的数据定义那些质量规则。不要在迁移期间清理数据。要么之前做，要么之后做。根据数据量和所使用平台的限制，估计执行迁移所需的时间。然后，在可能的情况下，将数据保持在客户的控制和责任范围内，这样您就可以保持法律方面的简单。

[00:08:54]现在我们来谈谈方法。方法部分，这部分会[00:09:00]涵盖所有你可能用来移动数据的东西。比如，你要用什么过程?你打算怎么安排呢?您可能会在项目中使用什么方法?你该如何测试这类东西呢?

[00:09:15]首先是合同。我从一个顾问的角度来处理这个问题，但是你可以把这些信息，用在一个内部项目中因为你真的要在你和你的用户之间建立一个合同或者你的，或者任何这个项目的利益相关者之间。

[00:09:35]你要非常清楚每个阶段会发生什么。我建议您将项目分成两个不同的阶段。首先是发现和设计。然后是构建、测试和执行。原因是，我在很多项目中都见过，

[00:09:55]当你第一次进入环境[00:10:00]看客户的规格说明时，要真正理解有多少字段，有多少对象是非常困难的。为了真正理解实现移植需要做的事情的复杂性。所以，与其过度提交或过少提交，不如在开始项目之前，先从一个阶段开始看看所有要迁移的对象，所有你能得到的数据。

[00:10:30]达到一个你能更准确地估计一种支出类型的实施时间的程度。

[00:10:41]那么你应该在发现和设计阶段投入什么呢?因此，您需要了解数据迁移策略，即迁移的对象、方式、时间、地点和内容。您需要查看数据映射。所以[00:11:00]在对象和领域层面的数据映射。您希望进行什么样的高级转换?

[00:11:07]你要处理多少对象和字段?然后如果你把这些都拿走，构建的工作量将与对象和字段的数量成比例。

[00:11:24]这张幻灯片展示了数据策略文件的更多细节。我们将讨论如何进行迁移。那谁要对什么负责?您将使用什么环境?我们需要为我们设置任何服务器或任何云服务设置和初始化吗?

[00:11:49]如果出了差错，我们该怎么办?所以我们需要一个回滚策略。我们如何从目标环境中删除数据?我们将使用什么过程?谁来签字呢?[00:12:00]发布时间表。那我们什么时候做什么?谁来做这些活动?

[00:12:06]项目数据质量规则的定义。最后，我们将如何测试它，我们将如何记录数据迁移的处理过程，谁将签署它，以及如何报告它。

[00:12:25]数据迁移映射文档则更进一步。这很好地进入了设计部分，所以我们在这里试图描述与源和目标系统或对象相关的所有东西，我们要映射的字段，数据类型。我们真正想做的是让我们实现的事情尽可能简单。

[00:12:49]因此，我们正在寻找关于数据格式、字段大小、数据类型不匹配、复杂转换[00:13:00]的潜在问题，这些问题可能需要一个临时数据库来实现或一些真正的定制编码。然后，我们要制定出我们的执行命令。在Salesforce和许多系统中，你需要注意对象之间的关系你必须注意加载它们的顺序，

[00:13:17]例如，一个联系人不能在它是子帐户之前加载，因为它需要帐户ID来加载它，链接到一个。潜在的，你可以加载所有没有任何父ID的东西，然后在随后的更新中添加ID。然而，Salesforce中有很多对象现在不能工作，特别是在它们最详细的地方。

[00:13:41]所以你需要计划好加载每个对象的顺序，你可能需要计划好重新访问对象，当你在依赖树中发现循环时更新它们一次。

[00:13:59]那么，[00:14:00]我们该如何着手建造呢?我建议使用经典的ETL平台进行数据迁移。因此，我们将从源系统中提取数据，在某处进行分段，转换数据，然后将其加载到目标系统中。我将其分解为五份独立的工作。

[00:14:23]因此，为了便于测试，最好能够将源系统的阶段中的所有内容都拉到阶段数据库中，停止，然后检查我们是否拉出了预期的记录数量，是否没有得到任何错误消息，是否所有内容都加载正确，

[00:14:44]然后我们就可以开始绘图了。因此，通过将所有事情分解成不同的步骤，我们将每一步分离出来，我们可以单独测试每一步，我们可以重复每一步，而不必从头开始。所以如果我们[00:15:00]快到我们的过程的末尾，我们可以撤销一定数量的步骤，然后重做，而不必重做，清除所有的东西，然后重新开始，这是一个非常复杂的迁移，节省了很多时间和头痛。

[00:15:15]所以，我把它分解成这五个作业或过程:一个获取、一个映射、一个放置、一个删除和一个错误。get将所有内容拉出到登台数据库。这是正确的。将所有内容从源数据库提取到登台数据库中。映射部分执行所有转换，将输入模式更改为与目标模式非常相似的模式。

[00:15:40]这个地图唯一不能做的就是解析外键和引用。例如，如果我们将一个帐户加载到Salesforce，它会被赋予一个Salesforce帐户ID这将是记录中唯一的。当我们尝试加载联系人时，我们需要他们加载一个[00:16:00]帐户ID，它与他们的正确记录相匹配。

[00:16:04]我们在暂存数据库中有信息，告诉我们我们要找的帐户的ID是什么。我们将使用外部ID找到正确的帐户，然后使用该帐户的ID更新该帐户。这只会发生在流程的输入阶段我们已经输入了账户和联系人。

[00:16:32]你有时可以在地图上做这些事，但如果移动就会产生依赖性。这意味着必须先映射帐户，然后才能映射联系人，这可能不是您想要做的。所以如果你想保持垂直隔离，你要确保你能运行所有的get作业，然后是所有的map，然后是所有的put，而不是单独运行一个map和一个put之间的相互依赖。

[00:17:03]下面来看看跌期权的作用。它只是加载到目标系统中。这将从staging数据库中获取记录。这看起来很像目标，我们也在加载，然后把它推进去。它可能通过这个外键解析来查找外部id，父记录，或者查找我们要查找的值，

[00:17:23]但差不多就是这样然后它会报告这个过程和它的成功。最后两个过程是真正的帮助。你有一个delete，这是你对每个特定对象的回滚。还有一个运行，它允许你为一个实体或整个事物编排过程。

[00:17:44]你可以随心所欲地细细地说。在右边，我们有一个运行作业的例子它把gap, map, put，和delete链接在一起。所以，当你在调试或测试时，你会这样使用它，你必须一步一步[00:18:00]通过并执行这个过程。

[00:18:02]通读一遍，检查那里的日期，然后删除数据，使它干净，远离另一个错误。这是一个很好的过程。我们有一个对Salesforce数据的查询，然后我们将把它直接存入数据库表。现在，我们不打算改变模式。

[00:18:24]我们将在SQL数据库中创建一个复制表，它准确地反映了我们从源系统中提取的内容。然后我们可以用它来验证我们得到了正确的数据，我们也可以在之后回去。因此，如果我们到达流程的末尾，客户端检查数据并说，“哦，这个字段有一个问题，值是错误的，”我们可以追溯到它

[00:18:48]通过我们的staging表，一直回到我们提取的源记录，并验证数据是正确的，它已经被正确地关联起来，或者[00:19:00]我们可以识别在过程中日期字段转换错误的地方。这是一个典型的映射过程，所以我们现在从staging表加载，把记录拉出来，我们正在进行一些变换。

[00:19:16]所以重新编码，帐户引用，行业领域挑选需要修改或转换的列表。这就是我们要做的事情。输出是staging数据库中的映射表，它表示尽可能接近目标表结构。

[00:19:39]这里我们有一个看跌期权的过程，同样非常简单。它只是从数据库表中读取数据并将其推入目标系统。

[00:19:54]因此，运行put进程的结果是，我们会得到一个表，其中有[00:20:00]新创建的记录的一些id，所以我们可以通过delete操作将其推入Salesforce以删除它们。这里我们再次将这四个过程整合为一个。

[00:20:17]所以你可能会问，为什么我建议使用数据库来存放数据呢?在哪种情况下，我应该用它做什么?我发现这个数据库非常有用，特别是对于复杂的数据，数据迁移，因为它给了我一个地方来存放数据，然后再返回。我可以缓存我取出的数据，这样我就不必回到源系统再取出它。

[00:20:43]在过去，我遇到过一些数据收集速度很慢的情况。因此，您希望将从源系统提取数据的次数最小化，以加快端到端流程的速度。那么如何设置呢?好吧，将日志记录与[00:21:00]实际迁移数据分开。

[00:21:01]所以在SQLserver中，这将是两个不同的模式，并为表使用前缀，以便您可以在系统中跟踪实体。这里有源账户，这是从源表中提取的源数据。目标或TGT帐户将是转换数据，因此映射过程将构建TGT表。

[00:21:22]然后put过程就会生成out账户数据，它记录了实际加载到系统中的数据。任何引用数据会话都应该以ref作为前缀。因此，例如，如果要映射来自一个系统或另一个系统的用户，就需要一些引用用户表。所以你用这个前缀，它使它清晰。

[00:21:42]当你不小心装错东西的时候，每个表的目的是可以理解的。那么我们在测试数据时该怎么做呢?这是方法的最后一个领域。我们要确保它符合[00:22:00]生产数据质量。万博max手机网页登录使用生产数据进行日常测试。万博max手机网页登录

[00:22:03]也就是说，那会很麻烦。因此，在进行测试时，您可能必须实现控制对该系统的访问的过程，以确保您会按照适当的规定购买它。使用数据库作为您的测试的审计日志和证明。因此，要建立这些kpi，并进入审计

[00:22:25]跟踪你的过程，这样就可以很容易地运行SQL收回，你知道，在执行过程中运行一个报告，然后说，这是结果。事情是这样的。你也不必翻看日志文件，试图解决问题。

[00:22:41]这是测试数据迁移的典型过程。您将有一个单元测试阶段，在这个阶段中，您将孤立地查看每个特定的作业，确保它独立工作。然后你会进行一些端到端测试，将整个系统构建在一起，并开始练习，了解处理代表性数据量需要多长时间。

[00:23:04]你的UAT阶段是让用户回到游戏中并让他们检查游戏是否正确。您希望最小化过程中所做的更改和修复的数量。如果不是实时数据的话，你确实需要对有代表性的数据进行测试。然后你要做一些排练，三到四次排练，可能是最好的。

[00:23:24]这样你就能在遇到问题之前把它们解决掉。否则，当它们在周末上线时，您将熬夜到午夜，试图修复一些您几周前就可以发现的数据问题。以上就是方法的内容。因此，将发现从交付中分离出来，就给了您重新评估一切的机会，并尽早就验证方法和测试职责达成一致。

[00:23:51]要明确谁在迁移过程中承担风险，特别是如果你在承包、使用时间和材料或固定价格。[00:24:00]那么，技术。为此，我们需要了解数据库迁移的源和目标。我们是从Salesforce到Salesforce，从SQL服务器到Salesforce CRM Dynamics?

(00:24:16)是的。我们在做什么系统?我们需要了解很多这方面的信息，了解我们在这方面的局限性。例如，在Salesforce中，我们是否能够在加载时关闭触发器和自动化以提高性能?如果我们这样做，我们将不得不或可能必须确保我们可以

[00:24:37]触发那些触发器将在迁移后运行的行为，或者我们需要将映射或编码的更改合并到我们的流程本身中。因此，我们可以使用的工具太多了，在选择这些工具时，我们可能要考虑数据量

[00:24:59][00:25:00]除此之外，你还可以使用Excel和Excel插件来加载文件，移动文件。Salesforce导入向导可以在大约50,000之后完成。我想那应该是很简单的唱片。只有一个对象，没有其他引用。也许Salesforce数据加载器，你可以做得更复杂一点。

[00:25:20]但是，对于大量的数据来说，这还是有点麻烦，因为要验证巨大的文本文件非常困难。然后您可以使用更多的商业产品，这可以使加载非常大的数据量和进行更复杂的转换万博max手机网页登录变得更容易。最后一个领域是技术限制。

[00:25:41]因此，尤其是Salesforce，你需要注意一些限制。例如，如果您正在使用批量API，那么在滚动的24小时内只能执行10,000个批次。我曾经在一些项目中使用过它，我们不得不将批大小减少到1到10条记录[00:26:00]，甚至是数千条记录

[00:26:02]而这会导致你超过这个极限。在这种情况下，如果你遇到这样的情况，即一次只能加载一条记录，因为在Salesforce中无法关闭各种触发器，你将不得不从使用bulk API切换到使用SOAP API，因为它没有相同的限制。

[00:26:19]它的运行速度不会那么快，但考虑到你一次写一条或两条记录，使用大容量也不会有什么好处。其他能抓住人们眼球的是，24小时内可以发布的20万个内容版本。如果你有超过20万个文件要加载到套接字Salesforce系统中，你不可能在。你不可能在24小时内加载并发布它们。

[00:26:56]所以你可能需要提前计划，因为[00:27:00]需要超过24小时的时间。

[00:27:04]总之，对于技术领域，找到所有的源系统，选择你已经知道如何使用的工具，然后检查你将在哪些限制下运行。

[00:27:20]现在，各位。因此，有很多人参与并进行数据迁移。首先我要讲的是数据所有者。所以他们是理解数据迁移重要性的人。他们实际上是被迁移的系统的所有者，他们现在将接受UAT和预演测试。

[00:27:45]所以是一个非常重要的人，他们需要承担所有的所有权，或者你必须有多个数据所有者，但理想情况下，一个人负责迁移的每个对象。客户端[00:28:00]可能是项目的赞助人。

[00:28:06]然后，数据所有者可能需要提名一个主题专家，这个专家应该是他们团队中真正了解数据中所有骨架隐藏在哪里的人。他们了解质量，他们可以帮助我们回答关于应该绘制什么图的问题。

[00:28:23]为什么数据是这样的?这将走向何方?它是如何使用的?这对项目至关重要。那么，开发团队就需要在每个角色中都有一个人，或者你可以在某个地方共享这些角色，但你需要团队中的人涵盖这些技能。

[00:28:44]我们需要一个项目经理来管理与客户的交互，跟踪里程碑，报告进展，保持事情一致，并帮助确定优先级。您需要一个数据迁移架构师，他将能够起草迁移策略并领导ETL开发人员。几个、一个或多个ETL开发人员根据迁移策略设计和构建ETL流程。

[00:29:10]可选的，一个DVA或访问一个你的体育场数据库，以确保它是适当调好的，并正确工作。然后一个真正好的测试，谁将能够验证迁移的数据和流程遵循设计，它是可接受的。

[00:29:32]金字塔的上面是技能区。所以我们需要有一个真正理解ETL技术的团队，特别是在开发团队中。如果数据SME的数据所有者也能理解这一点，那就太好了。所以我们需要告诉他们ETL流程是如何工作的，什么是唯一键，还有

[00:29:57]如果我们真的创造了那种东西，会发生什么呢?数据中小型企业将需要更多的数据知识，以及数据是如何移动的，因为他们将能够，我们将需要在这个层面上与他们讨论。因此，他们需要了解外键和单元键、实体关系图和字段元数据。

[00:30:20]现在，开发团队，他们真的需要精通ETL流程，最好是精通Salesforce 8个api，这样他们就可以避免Salesforce雕塑或其他的人，最好是选择一个团队，选择一套与该团队相匹配的工具，或一个与你想使用的工具相匹配的团队，这真的不是一个好主意开始

[00:30:44]用一套完全不熟悉的工具进行一次全新的迁徙，因为那将会贯穿整个山区时间。

[00:30:54]。在人群区总结一下。保持数据的清晰所有权。[00:31:00]很明显，它必须在项目结束时被企业或数据所有者接受。而获取中小企业的数据，简历是至关重要的。如果很难找到能回答相关问题的人，就会减慢项目的进度。

[00:31:14]回到那些被迁移的人然后，正如我前面提到的，选择一个知道您将要使用的工具的团队，或者选择您已经知道的工具，这应该确保成功。总的来说，数据迁移是困难的，但是有四个方面，我们可以想到四个关键领域来帮助我们成功，它们就是数据，方法、技术和人。

[00:31:47]非常感谢。有什么问题吗?谢谢你，马丁。是的。我要问了我希望观众可能会问或者不会问。第一个是，了解文档的重要性，并百分之百同意[00:32:00]您的观点。在他迁移之前，你有什么工具可以用来记录Salesforce的数据吗?

[00:32:06]还是大部分都是自己制作的，你知道，Excel表格或word文档之类的?所以大多数情况下，它最终是XL电子表格，因为它们是便携式的。你可以把它们交给别人，他们可以使用它们。我确实有一些在Python中构建的工具，可以轻松地将Salesforce元数据提取到表中，然后可以使用这些表。

[00:32:29]我做过一个项目，在谷歌电子表格中也写了一些东西，在tamps之间做一些检查，这样你就有了对象、字段和映射的选项卡，然后试着验证你映射的数据类型是正确的。但是，无论您采用哪种方式，都很难通信复杂的映射。

[00:32:48]所以，是的，有时候很棘手。是的。还没找到解决办法吗?不，还没有。[00:33:00]当我参与这样的项目时。看起来UAT是一个东西可能掉下来的地方，一个东西可能从裂缝中溜走的地方。你知道，开发团队的最大努力，即使他们，他们仍然会错过它，因为他们不是主题专家，有时主题专家没有像他们应该做的那样投入。

[00:33:18]你是否试图将UAT标准或测试计划写入合同中?或者把它写在什么地方了?你觉得写出来有多正式?诸如此类的事情。我认为，很难在合同中加入很多东西，你知道，关于移民的景观。我认为，关键之一是要清楚责任在哪里。

[00:33:46]我认为UAT应该由客户来完成，并由客户来领导，因为当涉及到过程时，他们必须接受数据。我认为在项目开始时要做的一件事就是要确定围绕这些数据的kpi是什么，它真正重要的是什么。

[00:34:08]所以如果是金融机构，那通常是钱。所以我们可能，例如，总结管理下的资产数量，并确保当我们迁移到那里时，我们在一定的容忍范围内，并尝试在任何可能的地方自动化测试，迁移，到几个简单的报告或查询，以获得良好的感觉，数据是正确的或错误的，

[00:34:34]然后进行有针对性的逐条跟踪，特别是可能有问题的记录。因此，在一开始进行一些数据质量分析是非常有用的，因为这可能会在源数据中抛出曲线球，从而可能在转换和迁移期间导致问题。

[00:34:55]所以你可以这样说，哦，好吧，我们有一个特殊的场景。[00:35:00]我们知道这会有问题。我们将为此创建一个测试用例。你会展示测试数据吗?我会详细讲解这方面的练习。所以你可以这样做，你知道，在你认为转型会很困难的领域，但也

(00:35:12)重要的客户。例如，您可能有一些非常知名的客户。你要确保他们的数据是正确的。在您的数据集中，一些不那么重要的客户甚至不需要那么担心。所以你会优先测试票价数据，确保它看起来正确，评估正确。

[00:35:31]真聪明。有没有SQL，既然你用的是关系数据库作为中间，你的缓存是不是，找个更好的术语?有没有一个你更喜欢的或者你认为更适合这个任务的，或者是更多的客户对客户的看法?我在笔记本电脑的SQL中构建了它，因为它是免费的。

[00:35:52]但是对于你的客户来说，微软已经在SQL server上做了同样的事情。[00:36:00]在SQL Server和MySQL的工作方式上有一些细微的不同，这改变了你能做什么。不过一般来说，我没有什么偏好。它实际上只是关于有一个地方来存储数据并运行一些报告之类的。

(00:36:14)是的。是的。我认为这是整个整合过程中令人着迷却常常被忽视的一部分，我非常感谢您今天的时间和您的专业知识。谢谢你，马丁。非常感谢。不客气