how do people feel about the PEAR db class?

[lawrence k]

I wrote a simple CMS for personal use. I'm thinking of using it for
other clients now. It's use of the database is slow and inefficient.
I'm thinking of switching to the PEAR class listed here:

http://pear.php.net/package/DB

What do people think of it?

[Richard Levasseur]

The DB class is just a wrapper and light abstraction for the various
databases php supports. It won't improve the efficency of your code,
for the most part. You should look at your queries and code to see if
you can cut some of the fat from it.

I highly suggest using it, however.

[Scott]

Indexes play a big part in database performance as well. Make sure you
are searching on indexed fields.

Scott

lawrence k wrote:

I wrote a simple CMS for personal use. I'm thinking of using it for
other clients now. It's use of the database is slow and inefficient.
I'm thinking of switching to the PEAR class listed here:

http://pear.php.net/package/DB

What do people think of it?

[NC]

lawrence k wrote:

I wrote a simple CMS for personal use. I'm thinking of using it for
other clients now. It's use of the database is slow and inefficient.
I'm thinking of switching to the PEAR class listed here:

http://pear.php.net/package/DB

What do people think of it?

Personally, I think it's a resource hog and a performance drag. As a
matter of fact, all DB abstraction layers are. For more information,
see here:

http://phplens.com/lens/adodb/

So you should avoid using abstraction layers whenever possible.

Cheers,
NC

[Jim Carlock]

"NC" <[e-mail]> posted:

For more information, see here:
http://phplens.com/lens/adodb/
So you should avoid using abstraction layers whenever possible.

Hello, NC,

The link you provided might be confusing to some. It specifically
describes their own ADODB thing, and fails to differentiate that
from Microsoft ADODB (which may or may not be realized by
the reader which then makes the link kind of confusing).

Abstraction layers usually provide something easier to use than
the root methods involved in connecting to databases and querying.
Sometimes they only provide friendlier names and run the same
code (perhaps with some error handling), so the end result may
that the only difference involved is the time it takes to set up the
call, and the time it takes to debunk the call, which in many cases
is something that network connections might be the only purely
visible wait. What I mean, is that IF you extract ALOT of data,
the network connection might be so slow and the processor then
waits upon the network to conclude its delivery. Another thing
involves the hard disk access speed, whereby the processor waits
on the hard disk to deliver the items to memory, which then waits
for memory to deliver the items to the nic, which then waits for
the nic to deliver the items to the host. All in all, the end user never
sees the processor wait the extra micro-second and even if they do
start timing it, the network connections are going to represent the
biggest bottle-neck.

Whew. Now, one needs to ask what the purpose of an abstraction
layer is. What exactly is the purpose? Only one answer exists and it
has nothing to do with speed. It's to provide a COMMON set of
routines to access any type of data. It ends up as an ease of use
thing:

(1) Connect to the db,
(2) Read such and such record from the db,
(3) Perform ops on the record retrieved (inspect it, is it the one you
really wanted?/modify it/delete it/present it to the end-user).
(4) Finish up with the recordset, close it out.
(5) Do some more work with the same connection or close the
connection.

Your final statement, "So you should avoid using abstraction layers
whenever possible," sat awkward and lacked an explanation, so I
took it upon myself to provide the information for the OP and anyone
else reading the thread (as well as myself).

Jim Carlock
Pos replies to the group.

[Richard Levasseur]

Just to justify NC a bit, PEAR::DB is a bit bloated and slow, and its
interface is cumbersome. It isn't the best database abstraction layer
out there. It is still, I believe, based upon and using PHP4
objects/concepts.

There is also the PDO stuff, I haven't looked that though, but I think
its a compiled (native C) thing, so it probably hauls ass.

That doesn't detract from Jim's statements about abstraction layers.
What abstraction layers lose in performance (which is miniscule, for
the most part), they gain in ease of use, portability, and
maintainability.

[NC]

Richard Levasseur wrote:

What abstraction layers lose in performance (which is miniscule,
for the most part), they gain in ease of use, portability, and
maintainability.

I respectfully disagree.

Ease of use is a matter of opinion; what is easy to me is not
necessarily easy to you and vice versa. Our discussion is the case in
point; you think it is possible to simplify database access by
introducing an abstraction layer, while I think that calls to native
API functions are simple enough... :)

Portability (if, in the context of this discussion, we define it as the
application's ability to use multiple database engines) and
maintainability are conflicting goals -- maintainability decreases with
the size of code base, while portability requires expansion of the code
base, so portable applications are by definition more difficult to
maintain. Code that does not rely on abstraction layers is by
definition more maintenable, simply because developers don't have to
maintain the abstraction layers themselves.

Loss of performance, however, is objectively measurable and LARGE (at
least, that's what phpLens benchmarks show, and, to the best of my
knowledge, no one has produced a benchmark test with markedly different
results). There is no evidence that points to "miniscule" performance
losses you spoke of; the evidence suggests that the losses are
substantial. If you are aware of any benchmarks that support your
claim, please share your knowledge, and I will happily reconsider my
position.

Cheers,
NC

[Richard Levasseur]

NC wrote:

Richard Levasseur wrote:

What abstraction layers lose in performance (which is miniscule,
for the most part), they gain in ease of use, portability, and
maintainability.
I respectfully disagree.

Ease of use is a matter of opinion; what is easy to me is not
necessarily easy to you and vice versa. Our discussion is the case in
point; you think it is possible to simplify database access by
introducing an abstraction layer, while I think that calls to native
API functions are simple enough... :)

Calls to native API functions are great, but i got tired of writing the
same code over and over, copy and pasting the same code over and over,
and generally adding more code that, when a change was required, forced
me to go back through it all and fix each independent instance.
Portability (if, in the context of this discussion, we define it as the
application's ability to use multiple database engines) and
maintainability are conflicting goals -- maintainability decreases with
the size of code base, while portability requires expansion of the code
base, so portable applications are by definition more difficult to
maintain. Code that does not rely on abstraction layers is by
definition more maintenable, simply because developers don't have to
maintain the abstraction layers themselves.
Just because there is a lot of code doesn't mean it isn't maintainable
(in the sense of, "I'm going to go smoke a pack of cigarettes before I
touch this, then call a therapist afterwards").

How an abstraction layer makes it more maintainable is it becomes
easier to make changes. You only have to do a couple of things
(function calls, object creations, whatever) to get the result you
need. As compared to making the same however-many api calls again. If
those api calls were always going to be that way, forever and ever,
then sure, the one with abstraction would be harder to maintain. But,
that is rarely (if ever?) the case (oh how I pray for such a day when
it's write once and never look at it again).

Now, which is more maintainable, the code where you simply tell the
abstraction you're working with something from somewhere else (putting
pgsql://: instead of mysql://), or go ing through and changing all the
mysql_ to pgsql_, add/remove the prepares/executes, change the
number_rows to numrows, etc etc.

Thats how an abstraction makes it more maintainable. Additionally, the
code the abstraction uses to interface to the underlying thing, be it a
database, file, whatever, is going to be seperate and (i hope to god)
self contained, again, making it easier to manage the seperate parts of
the abstraction.

Personally, I opt for the abstraction. It makes my life a lot easier
and I can get more done while leaving myself the option of adding more
faster.
Loss of performance, however, is objectively measurable and LARGE (at
least, that's what phpLens benchmarks show, and, to the best of my
knowledge, no one has produced a benchmark test with markedly different
results). There is no evidence that points to "miniscule" performance
losses you spoke of; the evidence suggests that the losses are
substantial. If you are aware of any benchmarks that support your
claim, please share your knowledge, and I will happily reconsider my
position.
Just to be clear, I'm not defending PEAR::DB's performance. It does
suck.
Another clarification I should make is that most abstractions don't
produce huge performance differences, I wasn't specifically refering to
only pear::db, because pear::db is sloooow compared to even my own
abstractions i've made. To be honest, after trolling through the
pear::db code, i've been weary of using anything from pear - but its
theres, it works, and it does what i need, so i use it.
Anyways, I'm not going to argue performance details, though, not for
anything PHP. I think it, for the most part, is silly because PHP is a
scripting language. Unless you're making some fundamental errors with
how you're processing the data, you're never going to get
whiz-ping-boing performance out of it, if you want that, you might want
to pick a lower level language and use PHP as the glue between it and
the web. Thats just my honest opinion though.
Cheers,
NC

Perhaps I'm a bit bias though. My specs change every day I come into
work, despite my meticulous planning and tearful, heart-wrenching pleas
to keep them the same until I, at the least, get the chance to say I
actually got something done.

-Richard

[David Quinton]

On Sun, 12 Mar 2006 14:16:28 GMT, "Jim Carlock" <an*******@127.0.0.1>
wrote:

"NC" <[e-mail]> posted:

For more information, see here:
http://phplens.com/lens/adodb/
So you should avoid using abstraction layers whenever possible.

Hello, NC,

The link you provided might be confusing to some. It specifically
describes their own ADODB thing, and fails to differentiate that
from Microsoft ADODB (which may or may not be realized by
the reader which then makes the link kind of confusing).

Abstraction layers usually provide something easier to use than
the root methods involved in connecting to databases and querying.
Sometimes they only provide friendlier names and run the same
code (perhaps with some error handling), so the end result may
that the only difference involved is the time it takes to set up the
call, and the time it takes to debunk the call, which in many cases
is something that network connections might be the only purely
visible wait.

I *think* (and I could be wrong) that Adodb and PhpLib also provide
some query-filtering that can help with security for people who could
otherwise be leaving themselves open to attacks?

Also Adodb now has what looks like a nice cacheing function (but I
haven't tried it)
--
Locate your Mobile phone: <http://www.bizorg.co.uk/news.html>
Great gifts: <http://www.ThisBritain.com/ASOS_popup.html>