Search Postgresql Archives

Re: Php abstraction layers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2005-30-08 at 21:00 -0700, Chris Travers wrote:
> Antimon wrote:
> 
> >Hi,
> >I'm working on a new web project based on php and i decided to use
> >PostgreSQL 8.x as
> >dbms. For triggers, views, stored procedures etc. I was going to write
> >a simple wrapper class and use pg_* functions. But some friends adviced
> >me to use an abstraction layer. I checked PEAR:DB and AdoDB. They look
> >pretty but i don't understand why sould i need one?
> >
> Do yourself a favor and write lightweight wrapper functions.  This means 
> that if something needs to be changed (say, a PHP API name change 
> happens) you don't have to rewrite a lot of your code.  Additionally, if 
> you do have to port someday to Interbase or even (gasp) MySQL, it 
> becomes possible thought not always straightforward.
>   *Simple* and light database abstractions are very nice because they 
> isolate your framework from the API syntax and after a few years, 
> something could change and then you don't have to rewrite a whole lot.
> 
I would have to agree with this.

As a network administrator I work with IP and MAC addresses alot, 
so I can use the extensive support for them as leverage when 
choosing a database for a project. That being said, I have other 
people to please and sometimes they get their way and I have to 
use MySQL. I do not to use PEAR or CPAN modules because I haven't 
had the time to learn their API's and don't know how secure they 
are.

As Chris suggests, I write wrapper functions to create and 
maintain one or more connections to the database as well as 
functions for inserting, updating, deleting and making 
different kinds of selections from the database. I have found 
it handy to store status, error and data in an array of 
associative arrays for each transaction with the database. The 
trick to making the code compatible is how and where the error 
and status data is stored. The PostgreSQL pg_ functions return 
quite different error and status information than the MySQL 
functions.

Another trick is to write wrapper functions that take a 
"driver" option to determine which "library" to use. Since the 
same array format is returned from either "library" the rest of 
the code doesn't need to know anything about the database.

One thing to take care with is ; making sure you escape any 
filter anything put into a database command to ensure that 
you don't create SQL injection vulnerabilities.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux