not HAL.... DAL!

Today I worked primarily on the DAL for the entire timberlake template system. This to say the least is a task and a half. However, if anyone can do it, it is me.

The first thing to remember about the DB abstraction layer is why it is there. First and foremost, it is there because let's say that you have all your information stored in a MySQL db, and then you decide to switch to Oracle because you are storing much more data than expected and what a more reliable interface. If you did not have a standardized db abstraction layer, then you would likely be doing every single call independently of one another. What this means is that when you switch, you will need to manually go in and change every single call to open a DB connection, every single call you make to query the db will need to be changed, probably some of the SQL itself will need to be changed. With a DB abstraction layer, you feed the layer information, the layer interpret's it, and then executes the command that you want. With this power, you now only have to change how one portion of your code interacts with the DB instead of every single line.

This hold a reasonable promise that if you ever do change DBs that your code will still work with relatively little modification. Powerful! That being said, they can be complex, depending on the need and on how OCD you are. LOL like me. I want to be able to do everything that you need to do, with options so that you can do it several different ways.

In any event, I think that this may be cut down to be more efficient and less friendly, with the main functions and specific views for standard information that is called regularly. Other than that it should be a little more abstract and a little less specific, but still with the view necessities.


Loushou.