远程访问其他DBMS

Question

请回答两个问题。

1)我正在阅读关于联邦存储引擎的文章，但对我来说，并不清楚简单的远程连接是否有好处。有什么区别或优势吗？

2)在这种情况下(真正的问题)：如果我有一个MySQL数据库，并且需要从其他数据库访问和读取敏感数据，可能是使用不同的DBMS，而且很可能，我只能访问read (无论如何，我不需要更多的权限来执行任务)。

Options

• 联邦存储引擎只解决MySQL数据库管理系统
• 数据库抽象库(pdo，zend)中的问题，
• 为每个外部数据库构建API，为每个外部数据库
• 同步与其他数据库(可能对此提议过高)

F 211

我需要的是：“约翰在你的数据库里?是的，不是。”

最好的选择是什么？

谢谢!

Answer 1

很难判断您是试图解决技术问题还是某种安全/管理问题。我将解决我认为是您实际的技术问题-确定用户是否在您的数据库中-并描述您的每一种可能性的权衡。让我们按复杂性顺序讨论可能的解决方案。

1.直接MySQL数据库连接

这将使用特定于MySQL的数据库驱动程序直接连接到远程数据库，并发出硬编码的SQL语句。如果您可以确保两端对模式有相同的知识，如果两端最好位于同一个内部网络上，并且您负责所有要连接和需要这些信息的客户端，那么这对内部使用是很好的。

2. PDO数据库连接

如果您对模式有一致意见，而不是数据库供应商(即一方可能使用PostgreSQL而不是MySQL)，那么PDO是一个更好的选择。只要查询相当简单，就不会遇到数据库兼容性问题。这是一个比#1更好的主意，因为它相当于相同的工作量，但更灵活。

3.数据库复制

在决定使用数据库复制之前，我建议非常谨慎。复制设置非常复杂，需要进行监督和管理。没有简单的复制设置。但是，如果：

1. 双方必须具有低延迟访问，或者
2. 想要抵御可能在另一方上运行的昂贵查询，或者
3. 需要关注网络可用性

。

如果您需要一些或所有这些特性，并且愿意支付的维护费用，那么它可能是正确的选择。请记住，处理复制需要做大量工作，并且它将把双方都绑定到同一个数据库供应商上。

4.联邦储存引擎

基于这些原因，我建议不要这样做：

操作系统提供的packages

• Weird组件并不总是包含
• 可选存储引擎，如果没有MySQL FEDERATED，就不能在MySQL数据库之间使用中断，这会引入新的失败类型，而不会有意义地简化应用程序代码

。

我在看这个引擎的选择，想知道它会有什么好处。我想，如果您将一个表从一个数据库移动到另一个数据库，但不想或不能更改查询它的应用程序代码，这可能是合适的，但我不认为这是预先设计的。如果不提高清晰度或业绩，它将是脆弱的。

5.编写API

在此之前的所有选择都假设您可以信任所有需要数据库凭据信息的人。如果您需要向第三方提供对此信息的访问权限，API是一个很好的选择，因为：

对API的database

• Using访问可以与单独管理，API不需要密码
• ，API将用户与内部数据库模式更改

隔离开来。

不过，API也有缺点：

对于数据库的codebase

• Generalized查询，
• APIs将同时增加代码和职责，这将需要大量的代码
• APIs，从而使您了解自己的安全问题(

)。

进一步的问题和说明

你说这是“敏感”信息。让我指出，对于PCI遵从性和HIPAA遵从性，以及您正在处理受法律保护的私有数据的其他情况，这些选项都是不合适的，因为它们都需要在不应该访问它的计算机之间解密和共享数据。当您从机器B查询机器A上的数据库时，很难确定内存中有多少数据副本。如果这是你的情况--私人的、加密的、受法律保护的数据--你将需要竭尽全力确保你的解决方案在法律上是合理的，而我无法就如何进行提供建议，只是说上述内容不够充分。

如果不是这样，我会说，就效率和简单性而言，内部使用的最佳解决方案是使用PDO (#2)。否则，构建一个API (#5)。