PEAR or ADOdb

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
theclay7
Forum Commoner
Posts: 50
Joined: Wed Feb 19, 2003 3:17 am

PEAR or ADOdb

Post by theclay7 »

there is an extension in PHP called PEAR, where we no longer need to connect to the DB using mysql_connect() but with
the embedded function such as DB:connect(), one of the main advantage is the ease of implementation if we want to change the db from mysql into Oracle....saves a lot of implementation time to rewrite!

I want to know the comparison of PEAR to ADOdb, which one is better to implement by their performance, functionality?

thanks
:lol:
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

Go to php.weblogs.com and check on the sideabars. As a whole, Adodb has much better performance than Pear, Metabase, MDB, and PHPLib. Another thing to consider is just how much functionality you need. If the answer is not much, consider Eclipse. Otherwise, Adodb is my suggestion.

[shameless plug warning]
If you are interested in sheer speed, you could check out Small Unit Raid at http://highsidecafe.com/mgaps/small_unit/index.php . I'm off the beaten path with this, but it's faster than the OO libs out there and provides a high level of abstraction. It has a lightweight feature set and is extremely easy to use. Now I just have to create support for db's other than MySQL.
[/shameless plug warning]

Cheers,
BDKR
fractalvibes
Forum Contributor
Posts: 335
Joined: Thu Sep 26, 2002 6:14 pm
Location: Waco, Texas

Post by fractalvibes »

BDKR,

Could you tell me what platforms we are speaking of and the context of ADODB? I use ADO everyday on IIS and with ASP, so the ADODB term certainly means a lot to me in that context. Are you speaking of the same thing that is near and dear to me within a IIS/PHP context? If not - I have some exploring to do!

thanks,

Phil J.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

I thik the best thing for you to do would be to check out the package for yourself.

http://php.weblogs.com/ADOdb

But I'll ramble a little anyways. To the best of my knowledge Adodb is not platform specific. I understand what you're getting at. My boss is a VB guy and we talk about it a good deal. AdoDB is a php based abstraction layer that is feature rich and very well tuned. Check it out!

Cheers,
BDKR
fractalvibes
Forum Contributor
Posts: 335
Joined: Thu Sep 26, 2002 6:14 pm
Location: Waco, Texas

Post by fractalvibes »

Many thanks - I will most certainly check it out!

Phil J.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

I sometimes wonder if database access layers are a good option. OK, it makes things easier for the programmer but isn't there a speed penalty compared to writing a simpler script tuned to a specific database?

Should we write code which best suits our needs as programmers or code which best suits the needs of our clients, ie the fastest possible solution?

Classes in general might also get a mention in this context..
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

McGruff wrote: I sometimes wonder if database access layers are a good option. OK, it makes things easier for the programmer but isn't there a speed penalty compared to writing a simpler script tuned to a specific database?

Should we write code which best suits our needs as programmers or code which best suits the needs of our clients, ie the fastest possible solution?

Classes in general might also get a mention in this context..
I hear exactly what you're saying. It seems that for the sake of the paradigm, we are comfortable with the OO speed hit. This isn't to say that OO is bad and/or should never be used. I use Objects as well. I just feel that in speed critical areas, and I consider dealing with a database to be one such area as it's one of the most lilely to become a bottleneck, objects aren't allways the best solution.

When I was doing a lot of messing around with the idea of structures in php, I found that abstraction could be acheived, ease of use, and with close to no speed hit compared to an OO approach. This ended up with Small Unit Raid. I guess it depends on just how much you really need in the way of functionality. If you don't need much, use Eclipse, if you want it all, use Adodb. If you want sheer speed, I say don't use objects at all (and give Small Unit Raid a look :o ).

Of course, from the viewpoint of a large team, many would consider the OO approach superior. In many of these cases, speed may not be the ultimate issue. Furthermore, it may be easier to create the entire thing using objects, get a product out the door, then come back later and tune specific areas of code (perhaps by taking a non OO approach) that may be bottlenecks.

To me, it's simple. If I'm worried about the ability to scale performance wise, then I'm more than willing to consider a non-OO tack.

Cheers,
BDKR
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Rgr. Some interesting points.
fractalvibes
Forum Contributor
Posts: 335
Joined: Thu Sep 26, 2002 6:14 pm
Location: Waco, Texas

Post by fractalvibes »

Interesting thread. On the one hand you need performance. On the other hand abstraction is nice - if your backend database changes, your app is less affected. Which is why such things as Web Services are becoming so popular - you are simply requesting the data without concern of the actual implementation and derivation of it.

Phil J
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

Which is why such things as Web Services are becoming so popular - you are simply requesting the data without concern of the actual implementation and derivation of it.
At this point, it's a question of whether or not you're providing data or a client that's just seeking it.

On a different note, I do believe that abstraction is not the sole right of OO. Abstraction can be had using something like structures in C. In this way, all bits of related data can be collected in and abstracted behind a name such as $queryStruct. All needed functions to get the query related information in queryStruct would act upon the structure as opposed to being part of it (making it a class). Using this approach, I get much more speed than the OO approach and still manage to maintain a high level of abstraction. Here is some code that uses this approach.

Code: Select all

# Create Structures.
$db_conn = new structDbConn;                  // The connection struct
$db_query = new structDbQuery;                 // The query struct

if(!SUR_connectToDb(&$db_conn, 'db'))    // Connect or do error stuff
    { echo $db_conn->error."\n";  exit; } 

$SQL="SELECT foo FROM bar LIMIT 0, 100";    // A select 
if(SUR_getData(&$SQL, '', &$db_conn, &$db_query)==true)
    { SUR_procResultSet(&$db_query); }    // Result set processed here
else
    { echo $db_query->error."\n"; break; }    // Error handling would go here
SUR_disConnect(&$db_conn);                 // Close connection 

# A test processing function
function display_info($row)
    { echo "$row[0]\n"; }
This approach turns out to be rather fast. :!: And inspite of not being OO, this could work with any db based on what the SUR_ functions are doing in the background.

But even still, this may depend on exactly what's being created and the work environ. If I need a feature rich set and db access is not likely to become a bottleneck, Adodb is real good. But with large sites that see tons of traffic, the db is allways going to become the weak link at some point. It seems that how we write our code is the deciding factor on when we get to that point.

Cheers,
BDKR (Terrence)
Post Reply