SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    PHP warrior dkode's Avatar
    Join Date
    Sep 2001
    Location
    Planet Namek
    Posts
    329
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    DB abstraction layer??

    I have read quite a few articles on using abstraction layers that basically takes all of the db functions and places them in seperate functions like so:

    PHP Code:
    function db_fieldname($lhandle,$fnumber) {
               return @
    mysql_fieldname($lhandle,$fnumber);
    }

    function 
    db_affected_rows($qhandle) {
        return @
    mysql_affected_rows();
    }
        
    function 
    db_fetch_array($qhandle) {
        return @
    mysql_fetch_array($qhandle);

    Now for some reason i find these functions more difficult to use then just doing something like:

    $num_rows = mysql_num_rows($result);

    what is the main purpose of using these abstraction layers and what do you think?
    "Mankind cannot define memory, yet it defines mankind"
    -- Project 2501, Ghost in the Shell

    Smarty | PEAR | PHP Manual | MySQL Manual

  2. #2
    Making a better wheel silver trophy DR_LaRRY_PEpPeR's Avatar
    Join Date
    Jul 2001
    Location
    Missouri
    Posts
    3,428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if you're trying to make something compatible with multiple DBs, then you might want to use something like that. but, if it's just for yourself with MySQL, i don't see any reason to use your own functions for affected_row(), fetch_array(), etc. i do use one for queries though so i don't have to do error checking on every query:

    PHP Code:
    function query($sql$ignore_err 0)
    {
        if (!(
    $r = @mysql_query($sql)) && !$ignore_err) { die('There was a problem with the database.'); }
        return 
    $r;

    i have that in my functions file, and then all i have to do is:

    $r = query('SELECT * FROM table');

    but to fetch the stuff i just use the regular functions. e.g.

    $row = mysql_fetch_array($r);
    - Matt ** Ignore old signature for now... **
    Dr.BB - Highly optimized to be 2-3x faster than the "Big 3."
    "Do not enclose numeric values in quotes -- that is very non-standard and will only work on MySQL." - MattR

  3. #3
    SitePoint Enthusiast spoorw8er's Avatar
    Join Date
    Oct 2001
    Posts
    56
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Like Dr_Larry said, if you only use one type of database and all you are going to do is pass thru the arguments straight to the language-provided function: don't do it, it hasn't any added value.

    But when you're tired of typing in the error-checking and handling code everytime you connect, query, insert, ... then creating some functions like Dr_Larry described one is very handy: it will save you typing time and your possible db-errors will always be handled in the same way.

    Another reazson is that you indeed might want to make your application work with different database engines and want to avoid you'll have to make changes in the core-logic of your application to accomodate for this (e.g. you want to avoid to go thru all your scripts changing mysql_whatever into oracle_whatever). If you have hidden the actual language provided function behind you're own (which also includes someerror checking and handling), you'll only have to change the code of those functions.

    Or in other words, only create/use an db-abstraction layer if there is enough added value in doing so (personally I think the error-checking thing in itself already makes it worthwhile).

    Maybe alos have a look at OO.
    In the following thread a number of concepts of OO are discussed, among others db abstraction layers when using the OO approach:
    http://www.sitepointforums.com/showt...threadid=36443

  4. #4
    SitePoint Evangelist thewitt's Avatar
    Join Date
    Apr 2001
    Posts
    468
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I did not believe these added any value either for my first two big website projects. I was using mSQL back in 1996 & 1997. mySQL was not quite a product.

    One of my ISPs dropped support for mSQL and switched to mySQL. It took me weeks to update the software to the mySQL calls (several thousand perl programs). Later, one of my customers switched from mySQL to PostgreSQL. Same drill.

    I now use a database abstraction layer for all my projects, so I'll not get bitten like that again.

    If you are working commercially, all it takes is one change like this and a contract that does not protexct you from changes by the ISP, and you can lose the profits of your project very easily.

    -t


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •