ezSQL

OK,

I thought that this DB class deserved a topic of it’s own.

I’ve read the documentation and actually have started to read it again. It seems that this class really aleviates some of the pain and burden of ADOdb and Pear have.

I wonder like I mentioned before that this class deserves a place in MODx or not.

Since you’ve done the research, have you compared it to ADOdbLite? What are your thoughts/analysis of the major strenghts and weaknesses of each one?

Haven’t looked into ADOdbLite yet. Will check into later tonight.


However, ezSQL seems to be very light weight and to the point.

OK, finally got around to doing a little googling. I also took a look at ADOdb Lite. ADOdb Lite is a third party (aka fork) of ADOdb. Between ADOdb Lite and ezSQL -- I’m tending towards ez. (note: I’m not that great a programmer so my gut feeling my not be right).

Now, comparing ADOdb (full) to ezSQL -- IF I were a talentated programmer, I’d probably go with ADOdb and use only the libraries that would be need and cut out a majority of the ADOdb classes. sizewise ADOdb appears to sit at around the 200k mark and ezSQL at about 10k.

There was a full out thread at osC that had gone into a lot of this and a few other sites that are against abstraction all together. lolo, still they would recommend a good API instead. doh, API almost equals abrstraction layer. osC also did mention that most folks almost never change dbs mid-run. That is a good point but then osC is still basically mySQL only! So, that point is basically mute when you think of it from a larger view mainly being as users may not just be mySQL orientated. So, having a simple yet powerful and scalable abstraction layer will help most scripts target non-mySQL users, ie, PostGres, Oracle ...

My big concern in regards to this idea is what would happen if you got slashdotted? (./) Would ezSQL stand up to the punishment? I have a feeling that ADOdb would.

Next concern is why PHP decided to go with something internal (or was it?) -- Pear? Or is it Pear MDB?
If it was only politics then there shouldn’t be a big problem. However, I wonder how many servers actually have Pear enabled to begin with? Which would lead to ADOdb/ezSQL being a great fix for that.

homebrew vs 3rd party:
I am with the 3rd party crew. Out of plain simplicity. It’s been there and has been tested by a much larger audience. However, the name dropping does have it’s pros and cons. Being great for the added name value but possibly looked upon as having not been such and such’s favoirite option (brand loyalty).

Now, I spewed enough today ... would somebody with more experience in this area please reply? I really would love to hear the different opinions especially since I’m a few days/weeks away from porting code from basically straight mysql to one of these systems and could really use the advice -- would most likely save me oodles of hours possibly!

Thanks!!!

:)

Actually ADOdbLite is an officially recognized sister-project. Linked off of ADO’s front page in fact. It’s memory footprint goes from rougly 640Kb with the full implmentation down to 59Kb.

You’re right about the links and such.

However, looking at the commands and at the file I downloaded it seemed that it had a few less abilities than ezSQL. Which I do like the idea of using previous queries again.

However, if ADOdb lite was used the option of upgrading to the full parent would be that much easier.

hmmmmmm