我对数据库抽象层（dbal）有一些基本问题。我想对此有所了解。我已经知道dbal是一个应用程序编程接口。我使用PHP作为基本编程语言，并使用MySQL作为数据库，因此我的问题将基于此。让我们开始吧...
在更深层的意义上来说，MySQL Shell已经不是天才吗？ 我举一个例子，下面的命令将打印结果，我可以在脚本中处理它。所以在我看来，它像是一种api，是一种非常糟糕的api，但它可以正常工作。
mysql --batch -u root -p -e "select * from foobar"
MySQL改进的扩展和PHP数据对象是否还不错？ 我会说是的，因为它为我提供了一个很好的API，用于处理PHP中与数据库相关的内容。
很长时间以来，我认为在一个api中处理不同的数据库是dbal的主要思想。但是我意识到这与数据库无关，而不是dbal。因此，当dbal可以处理多个数据库时，它就与数据库无关，对吗？
最后一个问题。在讨论了这个主题之后，我意识到dbal就是门面。那么每个dbal都是一个编程接口，这必须意味着每个api在设计模式方面都是一个立面吗？这样对吗？
感谢您的帮助：）
答案 0 :(得分：2)
尽管您可能会争辩到任何隐藏与数据库的低层通信细节的API都是字面上的“抽象层”，但术语“数据库抽象层”通常用于指代更具体的API的类型。
我希望DBAL至少有能力支持一种以上的DBMS；名称中的“抽象”表示API没有与一个基础协议或驱动程序紧密耦合。
MySQLi PHP extension本身称为“连接器”，它包装了较低级别的“驱动程序”，尽管该术语并不是特别流行。对于大多数PHP用户而言，它只是与该DBMS功能紧密相关的“ MySQL驱动程序”。
PHP的PDO扩展无疑可以看作是DBAL，因为它统一了对各种数据库驱动程序的访问，并抽象了一些概念，例如查询参数。另一方面，它是相当“低级”的抽象，因为它暴露了底层系统的许多复杂性。 The introduction in the manual将其称为“数据访问抽象层”，与“成熟的数据库抽象层”不同。
另一方面，Doctrine DBAL为诸如事务之类的功能提供了更丰富的API，并且包括一个查询构建器，该构建器抽象了SQL语法的差异。使用PDO编写的代码仍然需要针对特定的DBMS使用正确的语法和选项，而使用Doctrine DBAL编写的代码理论上可以在任何受支持的DBMS上运行而无需修改。
甚至可能有更丰富的抽象，例如对象关系映射器，例如Doctrine ORM。尽管严格地说，它们确实提供了抽象数据库的层，但通常将它们称为DBAL。
请记住，所有这些只是为了方便地引用事物-没有法律规定应用程序必须使用一组特定的层，或者这些层必须属于某些类别。设计模式也是如此，因此在一般情况下，您对Facade模式的问题并不是真正可以回答的-如果您要实现DBAL，则可以使用Facade模式作为结构化指南。但是您可能会在无法理解架构的有用环境下工作。