ADOdb feedback?
Moderator: General Moderators
ADOdb feedback?
Currently, I am just using straight built-in functions for handling data access, I'd like to switch over to using something a little more simplified and with more features....
Has anyone used ADOdb http://adodb.sourceforge.net/ and is happy with it? Or, do you have other suggestions... there are tons of classes out there.. and I just want to pick something that will be scalable for the long term.
Has anyone used ADOdb http://adodb.sourceforge.net/ and is happy with it? Or, do you have other suggestions... there are tons of classes out there.. and I just want to pick something that will be scalable for the long term.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Personally I have always found database abstraction layers less portable than they dictate...you still have to know the nuances of the different SQL platforms to use a abstraciton layer effectively, otherwise you will still write MySQL specific code like this in the query functions:
MSSQL from what I remember doesn't support LIMIT so obviously the above hardcoded SQL statement will choke when you switch over to a MSSQL from a MySQL server. Thus the database abstraction layer does little to save the day.
They all offer little speed up functions and helpers to prevent the above scenario from occuring but IMHO that is a waste of time. Not to mention the waste of clock cycles consumed by most bloated DB abstraction layers...even AdoBD lite is overkill IMHO.
I say your better off studying the data access layer/table data gateway.
Cheers
Code: Select all
SELECT * FROM table LIMIT $offset, $lengthThey all offer little speed up functions and helpers to prevent the above scenario from occuring but IMHO that is a waste of time. Not to mention the waste of clock cycles consumed by most bloated DB abstraction layers...even AdoBD lite is overkill IMHO.
I say your better off studying the data access layer/table data gateway.
Cheers
Well I'm only using MySQL... I've always thought of these to be overkill as well... but as I start to add a lot of queries, i'm basically doing tons ofHockey wrote:Personally I have always found database abstraction layers less portable than they dictate...you still have to know the nuances of the different SQL platforms to use a abstraciton layer effectively, otherwise you will still write MySQL specific code like this in the query functions:
MSSQL from what I remember doesn't support LIMIT so obviously the above hardcoded SQL statement will choke when you switch over to a MSSQL from a MySQL server. Thus the database abstraction layer does little to save the day.Code: Select all
SELECT * FROM table LIMIT $offset, $length
They all offer little speed up functions and helpers to prevent the above scenario from occuring but IMHO that is a waste of time. Not to mention the waste of clock cycles consumed by most bloated DB abstraction layers...even AdoBD lite is overkill IMHO.
I say your better off studying the data access layer/table data gateway.
Cheers
Code: Select all
$query ="select.."
$results = mysql_fetch_array($query);
etc. etc.Maybe I'll just create a simple layer for the shorter syntax... I dunno....
If you'd bothered to read the documentation for ADODB and ADODB Lite you'd know that they both support the $db->SelectLimit method to add native select limiting code for MySql, MySqli, MySqlt, SqLite, PostGres7, MsSql, MsSqlpo, and Sybase. But hey, I'm sure it's easier to think you know it all and spread a little FUD here than do a bit of research first.Hockey wrote:Personally I have always found database abstraction layers less portable than they dictate...you still have to know the nuances of the different SQL platforms to use a abstraciton layer effectively, otherwise you will still write MySQL specific code like this in the query functions:
MSSQL from what I remember doesn't support LIMIT so obviously the above hardcoded SQL statement will choke when you switch over to a MSSQL from a MySQL server. Thus the database abstraction layer does little to save the day.Code: Select all
SELECT * FROM table LIMIT $offset, $length
On topic, I use ADODB Lite and I bloody love it. It's well written, quick, and it makes doing database stuff easier to debug. All good reasons to learn it and use it on production sites in my opinion.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Calm down...onion2k wrote:If you'd bothered to read the documentation for ADODB and ADODB Lite you'd know that they both support the $db->SelectLimit method to add native select limiting code for MySql, MySqli, MySqlt, SqLite, PostGres7, MsSql, MsSqlpo, and Sybase. But hey, I'm sure it's easier to think you know it all and spread a little FUD here than do a bit of research first.
I was aware of SelectLimit() but in my experience most people end up using the generic Execute() where I often see MySQL specific code, not portable...
I thought I insinuated that when I said:
I wasn't spreading FUD I was just voicing my professional opinion and personal experience...apparently the truth hurts as you seem to use it and seem to have been irritated by my statements...They all offer little speed up functions and helpers to prevent the above scenario from occuring but IMHO that is a waste of time.
There is not FUD in that abstraction layers do ad a lot of overhead, especially if he's going to use JUST MySQL...
He could simply implement an object wrapper around the MySQL API to reduce calls, etc...
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Programmers in the 60's & 70's saved a lot of time & space on their servers by JUST using 2 digits for the year field. When they were programming, they thought "this program will only be used in this century"
. Point being is that you shouldn't paint yourself into a corner by assuming your situation in the future will be the same as it is now. In short - use a DB abstraction layer (DBAL).
~hockey you're right that a lot of DBALs add overhead & if you were coding while considering nothing but speed, you should definitely hard code everything. However the amount of overhead they add (of course depending on the DBAL you choose) becomes trivial when you are changing database systems. What if right now he uses the mysql... functions but decides to go with the mysqli... functions in the future? I'd rather only have to change one class & the functions it references than have to pour through my entire project looking for mysql_query(), mysql_fetch_row(), etc.
I've never used ADOdb, but I have used ADOdb Lite in the past. Personally I find ADOdb Lite a tiny bit more cumbersome than my own, home grown DBAL, but that could easily be because... I wrote my own.
If you're somewhat new to PHP & databases, I'd recommend using ADOdb Lite - it's probably one of the best out there.
~hockey you're right that a lot of DBALs add overhead & if you were coding while considering nothing but speed, you should definitely hard code everything. However the amount of overhead they add (of course depending on the DBAL you choose) becomes trivial when you are changing database systems. What if right now he uses the mysql... functions but decides to go with the mysqli... functions in the future? I'd rather only have to change one class & the functions it references than have to pour through my entire project looking for mysql_query(), mysql_fetch_row(), etc.
I've never used ADOdb, but I have used ADOdb Lite in the past. Personally I find ADOdb Lite a tiny bit more cumbersome than my own, home grown DBAL, but that could easily be because... I wrote my own.
If you're somewhat new to PHP & databases, I'd recommend using ADOdb Lite - it's probably one of the best out there.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
You said, and I quote:Hockey wrote:I was aware of SelectLimit() but in my experience most people end up using the generic Execute() where I often see MySQL specific code, not portable...
I thought I insinuated that when I said:
I wasn't spreading FUD I was just voicing my professional opinion and personal experience...apparently the truth hurts as you seem to use it and seem to have been irritated by my statements...They all offer little speed up functions and helpers to prevent the above scenario from occuring but IMHO that is a waste of time.
An abstraction layer is exactly the right solution to the LIMIT problem you came up with, yet in your "professional" opinion you're trying to say it isn't the right way to interact with a database and using an abstraction layer is a bad idea. That's FUD. Plain and simple.MSSQL from what I remember doesn't support LIMIT so obviously the above hardcoded SQL statement will choke when you switch over to a MSSQL from a MySQL server. Thus the database abstraction layer does little to save the day.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Adodb Lite - I use it regularly and switch across mysql, mysqli and postgres. mysql native driver is also inbound very soon. Then there's PDO...
. The main feature of ADOdb Lite is speed it's faster and uses less memory than the stock ADOdb, and it's also a *lot* easier to modify when needed since it follows a much cleaner design.
Of course a next possible step up the abstraction ladder is an ORM, ActiveRecord, DataMapper, or other similar scheme for moving towards a more Object oriented abstraction layer. I've built such in the past on top of ADOdb Lite, and PDO. Or you can use the existing solutions like Propel.
Of course a next possible step up the abstraction ladder is an ORM, ActiveRecord, DataMapper, or other similar scheme for moving towards a more Object oriented abstraction layer. I've built such in the past on top of ADOdb Lite, and PDO. Or you can use the existing solutions like Propel.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I never said it wasn't the right way to interact with a database I just mean it's not the BEST way to deal with databases.onion2k wrote:An abstraction layer is exactly the right solution to the LIMIT problem you came up with, yet in your "professional" opinion you're trying to say it isn't the right way to interact with a database and using an abstraction layer is a bad idea. That's FUD. Plain and simple.
My only point with the statement you quoted. Was that many times people use database abstraction layers and still use hardcoded MySQL statements, in this case porting over to MSSQL is just as much, if not more work than using a low over head table data gateway.
Would ADOdb lite make switching to stored procedures any easier? I could see that as a pretty big benifit.
Also, I could see using both ADOdb and built-in functions for mysql... let's say you have a site that produces a widget and there is one set of code that is used for the widget which receives the bulk of the traffic... use the built in functions for that.. then ADOdb for everything else... (admin)
Also, I could see using both ADOdb and built-in functions for mysql... let's say you have a site that produces a widget and there is one set of code that is used for the widget which receives the bulk of the traffic... use the built in functions for that.. then ADOdb for everything else... (admin)
It wouldn't help, but it wouldn't hinder you either. Accessing stored procedures is a change to the SQL you write, not a change to the way you run such SQL statements.GeXus wrote:Would ADOdb lite make switching to stored procedures any easier? I could see that as a pretty big benifit.
That sounds like a very bad idea to me. You'd have to maintain two separate sets of code which are both doing the same thing (connection to the database), and you'd have two different paradigms within the PHP code (interacting with the database with the library and interacting with the database with the native functions). It'd be a lot tidier, easier to maintain, and easier to produce good code if you pick one option. Personally that option would be the use of a library, namely ADODB Lite.GeXus wrote:Also, I could see using both ADOdb and built-in functions for mysql... let's say you have a site that produces a widget and there is one set of code that is used for the widget which receives the bulk of the traffic... use the built in functions for that.. then ADOdb for everything else... (admin)
Here's an example of why I use ADODB Lite:
Using ADODB Lite I can loop through it's query list array and produce a list of all the SQL queries in a page with the time each one took and any error it produced and pass it to my error handler object. This produces a nicely formatted <div> in the page that shows me at a glance which SQL statement took a long time.
Code: Select all
$errorHandler->addDebug("Database queries: ".count($databaseLink->query_list));
if (ADVANCED_SQL_DEBUG==true) {
for ($x=0;$x<count($databaseLink->query_list);$x++) {
if ((ADVANCED_SQL_DEBUG_LONG_QUERY_ONLY==true and $databaseLink->query_list_time[$x]>ADVANCED_SQL_DEBUG_LONG_QUERY_TIME) or ADVANCED_SQL_DEBUG_LONG_QUERY_ONLY!=true) {
$errorHandler->addDebug("<small><i><span style="color: red;">".$databaseLink->query_list[$x]."</span> (Time:".number_format($databaseLink->query_list_time[$x],4).") ".(!empty($databaseLink->query_list_error[$x])?"<br />(Errors:".$databaseLink->query_list_error[$x].")":"")."</i></small>");
}
}
}
echo $errorHandler->drawErrors();
On a dev site it dumps them to the browser, on a production site I can change the config to log slow SQL queries into a database table. For debugging a slow page it's a godsend.
Doing that using only native functions is impossible. You could write your own wrapper to do the same thing ... but why bother when ADODB Lite already does it?
onion2k wrote:It wouldn't help, but it wouldn't hinder you either. Accessing stored procedures is a change to the SQL you write, not a change to the way you run such SQL statements.GeXus wrote:Would ADOdb lite make switching to stored procedures any easier? I could see that as a pretty big benifit.
That sounds like a very bad idea to me. You'd have to maintain two separate sets of code which are both doing the same thing (connection to the database), and you'd have two different paradigms within the PHP code (interacting with the database with the library and interacting with the database with the native functions). It'd be a lot tidier, easier to maintain, and easier to produce good code if you pick one option. Personally that option would be the use of a library, namely ADODB Lite.GeXus wrote:Also, I could see using both ADOdb and built-in functions for mysql... let's say you have a site that produces a widget and there is one set of code that is used for the widget which receives the bulk of the traffic... use the built in functions for that.. then ADOdb for everything else... (admin)
Here's an example of why I use ADODB Lite:
Using ADODB Lite I can loop through it's query list array and produce a list of all the SQL queries in a page with the time each one took and any error it produced and pass it to my error handler object. This produces a nicely formatted <div> in the page that shows me at a glance which SQL statement took a long time.
What this produces looks like this:Code: Select all
$errorHandler->addDebug("Database queries: ".count($databaseLink->query_list)); if (ADVANCED_SQL_DEBUG==true) { for ($x=0;$x<count($databaseLink->query_list);$x++) { if ((ADVANCED_SQL_DEBUG_LONG_QUERY_ONLY==true and $databaseLink->query_list_time[$x]>ADVANCED_SQL_DEBUG_LONG_QUERY_TIME) or ADVANCED_SQL_DEBUG_LONG_QUERY_ONLY!=true) { $errorHandler->addDebug("<small><i><span style="color: red;">".$databaseLink->query_list[$x]."</span> (Time:".number_format($databaseLink->query_list_time[$x],4).") ".(!empty($databaseLink->query_list_error[$x])?"<br />(Errors:".$databaseLink->query_list_error[$x].")":"")."</i></small>"); } } } echo $errorHandler->drawErrors();
On a dev site it dumps them to the browser, on a production site I can change the config to log slow SQL queries into a database table. For debugging a slow page it's a godsend.
Doing that using only native functions is impossible. You could write your own wrapper to do the same thing ... but why bother when ADODB Lite already does it?
Ok I'm sold