既然我们有了 PDO，那么抽象数据库处理是否有意义？答案

【问题标题】：Does it make any sense to abstract database handling now that we have PDO?既然我们有了 PDO，那么抽象数据库处理是否有意义？
【发布时间】：2012-01-04 23:44:33
【问题描述】：

我正在尝试创建一个用于学习目的的数据库抽象类，您可以通过执行以下操作来创建与您拥有驱动程序的任何数据库的多个连接：

//Create multiple database connections
$db1 = new DatabaseFactory("MySQL","root","","localhost");
$db2 = new DatabaseFactory("MySQL","root","","localhost");

或者...

$db = new DatabaseFactory("SQLite");

但我不得不考虑一下，除非您需要管理与工厂对象的多个连接，否则随着 PDO 的出现真的不需要这样的东西，对吗？

我的问题是，您认为对 PDO 进行更多抽象层有用吗？为什么？

【问题讨论】：

标签： php database pdo database-abstraction

【解决方案1】：

如果严格考虑数据库级别的操作抽象，而不是像 ORM 这样的东西，那么仍然存在不同数据库之间的 SQL 支持问题。

例如，比较 SQLite、Postgre 和 MySQL，它们都支持大部分相同的语法，但它们之间也存在各种差异。

PDO 没有采取任何措施来抽象出平台之间在 SQL 支持方面的差异。

还有一些其他的东西可以使用另一层来隐藏。但是，它是否非常可行有点令人怀疑。例如，考虑尝试使用软件来模拟 SQLite 等中的外键检查。

【讨论】：

如果您要使用特定的数据库，我假设您了解它的特定 SQL 细微差别。同样，我明白你的意思。如果有一天我想将数据库从 MySQL 切换到 Postgre，由于我正在使用现有的 SQL 语句，它可能会破坏我的应用程序。
@cilosis 有些人喜欢使用 sqlite 进行开发，而其他一些重型数据库则用于生产。我自己不喜欢这个，但我可以看到在你的开发机器上拥有一个最小环境的吸引力。如果我的大部分代码不是特定于数据库的，我可能会自己做。

【解决方案2】：

虽然 PDO 是对旧 mysql 函数存储桶的重大改进，但它仍然是用于访问数据库的非常低级的 API。

所以是的，在大多数情况下，围绕它封装更高级别的 API 仍然有意义。

例如，可以使用更高级别的 API 使 SQL 注入攻击几乎不可能。

【讨论】：

如果您将其 api 用于准备好的查询，PDO 已经这样做了（防止 sql 注入）
当然，但是包装器也可以利用 PDO 的内置安全功能，提供更好的访问方式。