请回答两个问题。
1） 我正在阅读关于联邦存储引擎的文章，但对我来说，不清楚简单的远程连接是否有优势。有什么不同或优势吗？
2） （真正的问题）在这种情况下：如果我有一个MySQL数据库，我需要访问和读取其他数据库中的敏感数据，可能是使用不同的DBMS，而且可能我只有读取权限（无论如何，我不需要更多的权限来执行任务）。
选项
- FEDERATED存储引擎仅解决MySQL DBMS中的问题
- 数据库抽象库
- 为每个外部数据库构建一个API
- 将我的数据库与其他数据库同步（可能对这个提议有些过头了）
我只需要："约翰在你的数据库里？是的，不是"
什么是最好的选择？
谢谢！
很难判断您是在试图解决技术问题还是某种安全/管理问题。我将解决我认为是您实际的技术问题——确定用户是否在您的数据库中——并描述每种可能性的权衡。让我们按照复杂性的顺序来讨论可能的解决方案。
1.MySQL数据库直接连接
这将使用MySQL特定的数据库驱动程序直接连接到远程数据库，并发布硬编码的SQL语句。如果您可以确保两端对模式有相同的了解，如果两端最好在同一个内部网络上，并且您负责将要连接并需要这些信息的所有客户端，那么这对于内部使用来说是可以的。
2.PDO数据库连接
如果你对模式达成了一致，但对数据库供应商没有达成一致（即一方可能使用PostgreSQL而不是MySQL），那么PDO是一个更好的选择。只要您的查询相当简单，就不太可能遇到数据库兼容性问题。这是一个比#1更好的想法，因为它相当于相同的工作量，但更灵活。
3.数据库复制
在决定使用数据库复制之前，我建议您格外小心。复制的设置很复杂，需要监督和管理。没有简单的复制设置。但是，如果：
- 双方都必须具有低延迟访问，或者
- 一方希望隔离可能在另一方上运行的昂贵查询，或者
- 存在对网络可用性的担忧
如果您需要这些功能中的部分或全部，并且愿意支付维护费用，这可能是正确的选择。请记住，处理复制需要做大量的工作，而且它将把双方都绑定到同一个数据库供应商。
4.联邦存储引擎
我建议不要使用这个，原因如下：
- 操作系统提供的MySQL包中并不总是包含可选的存储引擎
- 没有被广泛使用的奇怪东西会毫无征兆地中断
- 由于
FEDERATED只在MySQL数据库之间工作，它引入了新的故障类型，而没有显著简化应用程序代码
我正在考虑这个发动机的选择，想知道它有什么好处。我想，如果您将一个表从一个数据库移动到另一个数据库，但不想或无法更改查询它的应用程序代码，这可能是合适的，但我不认为这是一个预先设计。如果不提高清晰度或性能，它将变得脆弱。
5.编写API
在此之前的所有选择都假设您可以信任所有需要数据库凭据信息的人。如果您需要让第三方访问这些信息，API是一个很好的选择，因为：
- 对API的访问可以与数据库分开管理
- 使用API不需要密码
- API将用户与内部数据库架构更改隔离开来
API也有缺点：
- API将代码和职责添加到代码库中
- 数据库的通用查询将需要大量代码
- API让您暴露自己的安全问题
进一步的问题和注意事项
你提到这是"敏感"信息。让我指出，对于PCI合规性和HIPAA合规性以及其他处理受法律保护的私人数据的情况，这些选项都不合适，因为它们都涉及在不应该访问数据的计算机之间解密和共享数据。当你从机器B查询机器a上的数据库时，很难确定内存中有多少数据副本。如果这是你的情况——私人、加密、受法律保护的数据——你需要竭尽全力确保你的解决方案在法律上是合理的，我无法就如何进行提供建议，只能说前面的内容不够。
如果不是这样的话，我认为就效率和简单性而言，内部使用的最佳解决方案是使用PDO（#2）。否则，构建一个API（#5）。