远程访问其他DBMS

Question

请问两个问题。

1）我正在阅读有关FEDERATED存储引擎的信息，但对我而言，目前尚不清楚简单的远程连接是否有优势。有什么区别或优势吗？

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

选项

• FEDERATED存储引擎仅解决MySQL DBMS中的问题
• 数据库抽象库（pdo，zend）
• 为每个外部数据库构建API
• 将我的数据库与其他人同步（对于此提议可能有点过分）

我需要的只是：“约翰在你的数据库中？是的，没有”

什么是最佳选择？

谢谢！

Answer 1

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

1。直接MySQL数据库连接

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

2。 PDO数据库连接

如果你对架构有共识，而不是数据库供应商（即一方可能使用PostgreSQL而不是MySQL），那么PDO是更好的选择。只要您的查询相当简单，您就不太可能遇到数据库兼容性问题。这比＃1更好，因为它相当于相同的工作量，但更灵活。

3。数据库复制

我建议在决定使用数据库复制之前要格外小心。复制设置很复杂，需要监督和管理。没有简单的复制设置。但是，如果符合以下条件可能是适当的：

1. 双方必须具有低延迟访问权限，或
2. 一方希望避免可能在另一方运行的昂贵查询，或
3. 关注网络可用性

如果您需要部分或全部这些功能且愿意支付维护价格，则可能是正确的选择。请记住，处理复制需要做很多工作，并且它会将双方绑定到同一个数据库供应商。

4。 FEDERATED存储引擎

出于以下原因，我建议不要使用它：

• OS提供的MySQL软件包中并不总是包含可选的存储引擎
• 未广泛使用的奇怪内容在没有警告的情况下中断
• 因为FEDERATED仅适用于MySQL数据库，所以它会引入新类型的故障而不会有效地简化您的应用程序代码

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

5。编写API

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

• 可以与数据库分开管理对API的访问
• 使用API​​不需要密码
• API将用户与内部数据库架构更改隔离开来

API也有缺点：

• API为代码库添加了代码和职责
• 广泛查询数据库需要大量代码
• API可以解决您自己的安全问题

进一步的问题和说明

您提到这是“敏感”信息。让我指出，对于PCI合规性和HIPAA合规性以及您处理法律保护的私有数据的其他情况，这些选项都不合适，因为它们都涉及在不应该访问它的计算机之间解密和共享数据。当您从机器B查询机器A上的数据库时，很难确定您将在内存中准确存储多少份数据。如果这是您的情况 - 私密，加密，受法律保护的数据 - 您将需要竭尽全力确保您的解决方案在法律上合理，我无法提供有关如何继续的建议，除了说前述不足。

如果不是这样，我会说在效率和简单性方面内部使用的最佳解决方案是使用PDO（＃2）。否则，构建一个API（＃5）。