数据库抽象层——那是什么？
Database abstraction layer - What is that?
我有一些关于数据库抽象层 (dbal) 的基本问题。我想对此有更好的理解。我已经知道 dbal 是一个应用程序编程接口。我使用 PHP 作为我的基本编程语言，MySQL 作为数据库，所以我的问题将基于它。让我们开始吧...
MySQL Shell 已经是更深层含义的 dbal 了吗？
我给你举个例子，下面的命令将打印结果，我可以在我的脚本中处理它。所以在我看来它像一个 api，一个非常糟糕的，但它会起作用。
mysql --batch -u root -p -e "select * from foobar"
MySQL 改进的扩展和 PHP 数据对象也是 dbal 吗？
我会说是的，因为它给了我一个很好的 api 来处理 PHP.
很长一段时间我都认为在一个 api 中处理不同的数据库是 dbal 背后的主要思想。但是我意识到这是数据库不可知的而不是 dbal。所以当一个 dbal 可以处理多个数据库时，它是数据库不可知的，我是对的？
最后一个问题。在我参与这个话题之后，我意识到 dbal 是门面。那么每个 dbal 都是一个编程接口，那一定意味着每个 api 都是设计模式意义上的外观？这样对吗？
感谢您的帮助:)
虽然您可能会争辩说任何隐藏了与数据库的低级通信细节的 API 是字面意义上的 "abstraction layer"，但术语 "Database Abstraction Layer" 通常是用于指代更具体的 API.
类型
我希望 DBAL 至少具有支持不止一种类型的 DBMS 的潜力；名称中的 "abstraction" 意味着 API 没有紧密耦合到一个底层协议或驱动程序。
MySQLi PHP extension 将自己称为 "connector"，它包裹了较低级别的 "driver"，尽管这个术语并不是特别普遍。对于 PHP 的大多数用户来说，它只是 "the MySQL driver"，与该 DBMS 的功能密切相关。
PHP的PDO扩展当然可以看作是一个DBAL，因为它统一了对各种数据库驱动的访问，并且抽象了一些查询参数等概念。另一方面，它是相当 "low level" 的抽象，因为它暴露了底层系统的许多复杂性。 The introduction in the manual 将其称为 "data-access abstraction layer"，与 "full-blown database abstraction layer" 不同。
另一方面，Doctrine DBAL 为交易等功能提供了更丰富的 API，并包含一个查询构建器，它抽象了 SQL 语法中的差异。为使用 PDO 编写的代码仍然需要为特定的 DBMS 使用正确的语法和选项，而为使用 Doctrine DBAL 编写的代码理论上可以 运行 在任何支持的 DBMS 上无需修改。
更丰富的抽象是可能的，例如对象关系映射器，例如 Doctrine ORM。这些通常不会被称为 DBAL，尽管严格来说它们确实提供了一个抽象数据库的层。
请记住，所有这些只是为了方便引用事物 - 没有法律规定应用程序必须使用一组特定的层，或者这些层必须属于特定类别。设计模式也是如此，因此在一般情况下，您关于 Facade 模式的问题并不能真正回答——如果您正在实施 DBAL，您可能会使用 Facade 模式作为如何构建它的指南；但您可能在这样的环境中工作，而这不是理解架构的有用方法。
我有一些关于数据库抽象层 (dbal) 的基本问题。我想对此有更好的理解。我已经知道 dbal 是一个应用程序编程接口。我使用 PHP 作为我的基本编程语言，MySQL 作为数据库，所以我的问题将基于它。让我们开始吧...
MySQL Shell 已经是更深层含义的 dbal 了吗？ 我给你举个例子，下面的命令将打印结果，我可以在我的脚本中处理它。所以在我看来它像一个 api，一个非常糟糕的，但它会起作用。
mysql --batch -u root -p -e "select * from foobar"MySQL 改进的扩展和 PHP 数据对象也是 dbal 吗？ 我会说是的，因为它给了我一个很好的 api 来处理 PHP.
中与数据库相关的东西
很长一段时间我都认为在一个 api 中处理不同的数据库是 dbal 背后的主要思想。但是我意识到这是数据库不可知的而不是 dbal。所以当一个 dbal 可以处理多个数据库时，它是数据库不可知的，我是对的？
最后一个问题。在我参与这个话题之后，我意识到 dbal 是门面。那么每个 dbal 都是一个编程接口，那一定意味着每个 api 都是设计模式意义上的外观？这样对吗？
感谢您的帮助:)
虽然您可能会争辩说任何隐藏了与数据库的低级通信细节的 API 是字面意义上的 "abstraction layer"，但术语 "Database Abstraction Layer" 通常是用于指代更具体的 API.
类型我希望 DBAL 至少具有支持不止一种类型的 DBMS 的潜力；名称中的 "abstraction" 意味着 API 没有紧密耦合到一个底层协议或驱动程序。
MySQLi PHP extension 将自己称为 "connector"，它包裹了较低级别的 "driver"，尽管这个术语并不是特别普遍。对于 PHP 的大多数用户来说，它只是 "the MySQL driver"，与该 DBMS 的功能密切相关。
PHP的PDO扩展当然可以看作是一个DBAL，因为它统一了对各种数据库驱动的访问，并且抽象了一些查询参数等概念。另一方面，它是相当 "low level" 的抽象，因为它暴露了底层系统的许多复杂性。 The introduction in the manual 将其称为 "data-access abstraction layer"，与 "full-blown database abstraction layer" 不同。
另一方面，Doctrine DBAL 为交易等功能提供了更丰富的 API，并包含一个查询构建器，它抽象了 SQL 语法中的差异。为使用 PDO 编写的代码仍然需要为特定的 DBMS 使用正确的语法和选项，而为使用 Doctrine DBAL 编写的代码理论上可以 运行 在任何支持的 DBMS 上无需修改。
更丰富的抽象是可能的，例如对象关系映射器，例如 Doctrine ORM。这些通常不会被称为 DBAL，尽管严格来说它们确实提供了一个抽象数据库的层。
请记住，所有这些只是为了方便引用事物 - 没有法律规定应用程序必须使用一组特定的层，或者这些层必须属于特定类别。设计模式也是如此，因此在一般情况下，您关于 Facade 模式的问题并不能真正回答——如果您正在实施 DBAL，您可能会使用 Facade 模式作为如何构建它的指南；但您可能在这样的环境中工作，而这不是理解架构的有用方法。