Re: Php abstraction layers

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? Project will be
postgre dependant because of the database structure, i don'T need to
support multiple dbms types. Since i may not even have a chance to
convert database structure. And php 5.1's postgresql library has all
new
features implemented.
In this situation, what would be the advantage of using an abstraction
layer?
Thanks.

> In this situation, what would be the advantage of using an abstraction layer?

NONE.

PEAR::DB is one of the worst classes in PEAR and has lots of ugly code
in it. AdoDB is IMHO a bit better, but as you said yourself, there is
not a single reason why you should go through all the trouble of using
DBMS abstraction layers, if you don't need them. The whole approche of
such things is quite daft, because they abstract your DBMS API, but
that's it. The different SQL implementations are not portable, not to
mention pl/xxx functions, triggers, rules etc. Such things are usually
advertised by users of stupid storage engines like MySQL, SqLite and
people with very little knowlege.

http://www.powerpostgresql.com/Downloads/database_depends_public.swf

Though it might be a good idea to write yourself a set of functions /
classes to handle escaping of data and make your DBMS work easier.

To prevent SQL injections in PHP5.1, take a look at pg_query_params().

Best regards,
Hannes Dorbath

Thanks for the reply.
I checked new 5.1 pg_ functions and i wanna ask something else. What do
you think about PDO? It is not an abstraction layer, just something
like wrapper. I thought as it supports both widely used dbmss, php
developers would focus on it more than pg or mysqli functions and that
can make it powerful.
Would it be a good decision to use PDO instead of pg_ functions?

> Would it be a good decision to use PDO instead of pg_ functions?

I don't see much benefits in using it, it just provides a common API
naming scheme. It's maybe easier in case you work with a gazillion
different DBMS and have trouble remembering function names, but that's
it. On the other hand it locks you out from special API features /
functions of PG. I wouldn't bother with it, especially not in your case.

Best regards,
Hannes Dorbath

"Antimon" <antimon(at)gmail(dot)com> writes:

> Thanks for the reply.
> I checked new 5.1 pg_ functions and i wanna ask something else. What do
> you think about PDO? It is not an abstraction layer, just something
> like wrapper. I thought as it supports both widely used dbmss, php
> developers would focus on it more than pg or mysqli functions and that
> can make it powerful.
> Would it be a good decision to use PDO instead of pg_ functions?

My understanding is that PDO is the way and the light. Use PDO.

Unfortunately my project began before PDO saw the light of day, but I plan to
migrate to it eventually.

--
greg

IMO I think it really depends on what you want to do. The
pg_functions are the *most* robust and full featured. There are
problems with PDO (mostly function related at this point). That
being said, PDO is great to work with when you get into it, and learn
your way around it. If your project is pgsql only and will only be
pgsql only, I'd suggest using the pg_ functions. I use both
extensively, but only use PDO on projects where I want other
programmers to be able to extend my work with other dbms support. If
you're new to PHP db programming, PDO might not be the easiest way to
go, it's still a little rough around the edges. Good luck and let me
know if you need any help with either. There's also a pgsql+php list
you might want to jump on: http://www.postgresql.org/community/lists/
subscribe and http://archives.postgresql.org/pgsql-php/

Regards,

Gavin

On Aug 30, 2005, at 8:00 PM, Greg Stark wrote:

> "Antimon" <antimon(at)gmail(dot)com> writes:
>
>
>> Thanks for the reply.
>> I checked new 5.1 pg_ functions and i wanna ask something else.
>> What do
>> you think about PDO? It is not an abstraction layer, just something
>> like wrapper. I thought as it supports both widely used dbmss, php
>> developers would focus on it more than pg or mysqli functions and
>> that
>> can make it powerful.
>> Would it be a good decision to use PDO instead of pg_ functions?
>>
>
> My understanding is that PDO is the way and the light. Use PDO.
>
> Unfortunately my project began before PDO saw the light of day, but
> I plan to
> migrate to it eventually.
>
> --
> greg
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

Gavin M. Roy
800 Pound Gorilla
gmr(at)ehpg(dot)net

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.

Best Wishes,
Chris Travers
Metatron Technology Consulting

On 31.08.2005 05:00, Greg Stark wrote:
> My understanding is that PDO is the way and the light. Use PDO.

Maybe you could provide some arguments on why it should be that?

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.

I wrote a wrapper class based on pg_ functions. Added some logging and
exception throwing capabilities etc.
I'm planning to use only prepared statements and pg_query_params
function when using user submitted data in queries to avoid
sql-injection. I believe it is enough but gonna do some tests.
This is the best way i think.

Thanks to everyone.