Database abstraction layer - What is that?

Question

i have some basic questions about database abstraction layers (dbal). I want to get a better understanding of that. I already know that a dbal is a application programming interface. I use PHP as my basic programming language and MySQL as database, so my questions will be based on it. Lets start ...

• Is the MySQL Shell already a dbal in the deeper meaning? I give you a example the following command will print the result and I can handle it on my script. So it seems to me like a api, a very bad one, but it would work.

  mysql --batch -u root -p -e "select * from foobar"

• Are MySQL Improved Extension and PHP Data Objects also a dbal? I would say yes, because it give me a good api for handling database related stuff inside PHP.

• A long time I thought that handling different databases in one api is the main idea behind dbal. However I realized that this is database agnostic and not dbal. So when a dbal can handle more than one database it's database agnostic, I'm right?

• So one last question. After I engage with this topic I realized that dbal's are facades. Well every dbal is a programming interface, that must mean, that every api is a facade in meaning of design pattern? Is this right?

Thanks for your help:)

Answer 1

While you could argue that any API which hides the detail of the low-level communication with the database is an "abstraction layer" in the literal sense, the term "Database Abstraction Layer" is generally used to refer to a more specific type of API.

I would expect a DBAL to have at least the potential to support more than one type of DBMS; the "abstraction" in the name implies that the API is not tightly coupled to one underlying protocol or driver.

The MySQLi PHP extension refers to itself as a "connector", which wraps a lower-level "driver", although this terminology isn't particularly widespread. For most users of PHP, it would simply be "the MySQL driver", closely tied to the features of that DBMS.

PHP's PDO extension can certainly be seen as a DBAL, in that it unifies access to various database drivers, and abstracts some concepts such as query parameters. On the other hand, it is quite a "low level" abstraction, in that it exposes a lot of the complexity of the underlying systems. The introduction in the manual refers to it as a "data-access abstraction layer", as distinct from a "full-blown database abstraction layer".

Doctrine DBAL , on the other hand, provides a richer API for features such as transactions, and includes a query builder which abstracts differences in SQL syntax. Code written to use PDO would still need to use the correct syntax and options for a particular DBMS, whereas code written to use Doctrine DBAL could theoretically run on any supported DBMS without modification.

Even richer abstractions are possible, such as Object-Relational Mappers, such as the Doctrine ORM . These would generally not be referred to as DBALs, although strictly speaking they do present a layer that abstracts databases.

Bear in mind that all of this is just convenience for referring to things - there's no law that an application must make use of a particular set of layers, or that those layers must fit in certain categories. The same is true of Design Patterns, so your question about the Facade pattern isn't really answerable in the general case - if you were implementing a DBAL, you might use the Facade pattern as a guide to how to structure it; but you might be working in a context where it was not a useful way of understanding the architecture.