Difference between Data Access layer and Database Abstraction Layer and refactoring the Database class [duplicate]

Question

Possible Duplicate:
What is the difference between Data Abstraction Layer & Data Acess Layer?

I just read up this article on nettuts. I got kinda confused. What's the difference between a Data Access Layer and a Database Abstraction Layer?

Also, should I make my own customized classes for this or is it better to use PDO?

I have a class DatabaseOps which performs all the CRUD operations. Other classes (eg. User) inherits from it and uses methods from this class to perform the CRUD actions. I have another class named Database which does the open connection, close connection, fetch array, confirming query, etc. Should I write them into a single class (Data Access/Abstraction Layer) ? Which one would be better?

Answer 1

A data access layer usually takes the form of an ORM. This allows you to map tables to objects. It provides a high level of abstraction so you don't necessarily have to worry about raw sql. http://en.wikipedia.org/wiki/Data_access_layer

A data abstraction layer creates an api that makes data access backend independent. Whether you are using postgres, mysql, sqlite, etc. It will allow you to query those databases without worrying about specifics. http://en.wikipedia.org/wiki/Database_abstraction_layer

If you are creating a platform that others can use, and they can choose their database backend an abstraction layer would be necessary, otherwise I wouldn't worry about it.

Whenever I have questions about web project structure, I always look at the popular MVC frameworks to see how they handled these problems. CakePHP, CodeIgniter, Kohana, are all great examples of how to create extendible object oriented frameworks. They are an indespensible resource when it comes to questions like this.

Answer 2

I am no perfect programmer, but but from what I have seen/learned it is important to have a separation of responsibilities. This is why abstraction layers are taught so heavily.

This is how I would look at it. Ask these questions...

1. Will you always use only one type of database?
2. If you do plan on using more than one type of database (or simply plan on making a project that is easier to configure...which I recommend) do all of the database commands (CRUD included) have the same syntax for accessing, deleting, inserting...? (Chances are they don't)

In my opinion, if I had to answer those questions I would put the two classes together. That way if your database ever does change you can fairly easily add a new abstraction layer to be called that has the access and CRUD commands, instead of making two different classes.

P.S. Excellent question! +1