數據庫抽象層-那是什么？

Question

我對數據庫抽象層（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在設計模式方面都是一個立面嗎？ 這是正確的嗎？

謝謝你的幫助：）

Answer 1

從字面上看，您可能會爭辯到任何隱藏與數據庫的低層通信細節的API都是“抽象層”，但術語“數據庫抽象層”通常用於指代更為特定的API類型。

我希望一個DBAL至少有潛力支持一種以上的DBMS。 名稱中的“抽象”表示API沒有與一個基礎協議或驅動程序緊密耦合。

MySQLi PHP擴展本身稱為“連接器”，它包裝了較低級別的“驅動程序”，盡管該術語並不是特別廣泛。 對於大多數PHP用戶而言，它只是“ MySQL驅動程序”，與該DBMS的功能緊密相關。

PHP的PDO擴展無疑可以看作是DBAL，因為它統一了對各種數據庫驅動程序的訪問，並抽象了一些概念，例如查詢參數。 另一方面，它是相當“低級”的抽象，因為它暴露了底層系統的許多復雜性。 手冊中的介紹將其稱為“數據訪問抽象層”，與“成熟的數據庫抽象層”不同。

另一方面， Doctrine DBAL為諸如事務之類的功能提供了更豐富的API，並且包括一個查詢生成器，該生成器抽象出SQL語法的差異。 使用PDO編寫的代碼對於特定的DBMS仍然需要使用正確的語法和選項，而使用Doctrine DBAL編寫的代碼在理論上可以在任何受支持的DBMS上運行而無需修改。

甚至可能有更豐富的抽象，例如對象關系映射器，例如教義ORM 。 盡管嚴格地說，它們確實提供了抽象數據庫的層，但是通常不會將它們稱為DBAL。

請記住，所有這些只是為了方便引用事物-沒有法律規定應用程序必須使用一組特定的層，或者這些層必須屬於某些類別。 設計模式也是如此，因此在一般情況下，您對Facade模式的問題並不是真正可以回答的-如果您要實現DBAL，則可以使用Facade模式作為結構化指南。 但是您可能會在無法理解架構的有用環境下工作。