Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

Best DB Abstraction Layer to use with Smarty
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> General
View previous topic :: View next topic  
Author Message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Thu May 15, 2003 5:45 pm    Post subject: Best DB Abstraction Layer to use with Smarty Reply with quote

Hi All.

I'm interested in knowing what the community thinks is the best/most popular db abstraction layer to use in conjunction with Smarty.
    Personally, I'm a fan of dbx which provides a very fast (module based) but minimal abstraction layer.
    I understand that ADODB's new experimental module is also very fast and more featured, but I have not tried it.
    Many talk of PEAR::DB though my understanding is that it is both somewhat slow and obtuse.

Experience (pros and cons), tips and code examples are welcome.
Back to top
View user's profile Send private message
sweatje
Smarty Regular


Joined: 17 Apr 2003
Posts: 70
Location: Bettendorf, Iowa, USA

PostPosted: Thu May 15, 2003 6:30 pm    Post subject: Reply with quote

I use ADOdb with no extensions.

This was an interesting post.

I used PEAR::DB in late 2001, but was burned by the fact that the syntax I tested in Oracle and Sybase failed to work in MySQL (as the readers quickly pointed out). They have probably fixed this by now, but I stoped using it. What was the point of a db abstraction layer that does not abstract?

I have been very happy with the ADOdb/Smarty combo.
_________________
Jason
jsweat_php AT yahoo DOT com
Back to top
View user's profile Send private message
toma
Smarty Regular


Joined: 25 Apr 2003
Posts: 62

PostPosted: Thu May 15, 2003 6:36 pm    Post subject: Reply with quote

From the php.net old news page:

[11-Jan-2003] The PEAR development team is proud to announce that PEAR is finally out of its long beta period. As of PHP 4.3, the PEAR installer is installed by default. Unix support is considered stable, while Windows and Darwin are still of beta-quality.

Because of this, I, personally, don't give any weight to arguments against it unless they are using a version from at least 11 Jan 03.

I love PEAR::DB and use it in every project I work on, from tiny 300hit/month idea sites to sites that get 9,000,000 hits/month.

My smarty w/ pear article shows how I setup my applications:
http://smarty.incutio.com/?page=SmartestSmartyPractices

Some code (not much however) can be found on my site: http://db.etree.org/source/
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Thu May 15, 2003 7:07 pm    Post subject: Reply with quote

@Toma: Well, Pear is still a mess on Windows. Also, I have yet to be given a reasonable argument as to why people should prefer Pear over any other library. After reviewing what is available there, I don't see the big deal. Please correct my misconceptions by providing some concrete examples, etc.
Back to top
View user's profile Send private message
sweatje
Smarty Regular


Joined: 17 Apr 2003
Posts: 70
Location: Bettendorf, Iowa, USA

PostPosted: Thu May 15, 2003 7:13 pm    Post subject: Reply with quote

More info:

Comparing PEAR DB to ADOdb

Also, toma, while PEAR 1.0 was officially release as of Jan 2003, PEAR::DB was some of the first code in PEAR. I think it is fair to make assessments on something that has been around of several years:

PEAR Release wrote:
PEAR 1.0 is released!
As of PHP 4.3.0, PEAR is an officially supported part of PHP. From this release, the PEAR installer with all its prerequisites is installed by default on Unix-style systems (Windows will follow in 4.3.2). It has been a long pregnancy.

Some historical highlights:

1999-11-21 : Malin Bakken was born
1999-11-22 : the first few lines of PEAR code were committed (DB.php)
2000-07-24 : the PEAR and PEAR_Error classes were born
2000-08-01 : first working version of the "pear" command
2001-05-15 : first contributor to base system
2001-12-28 : first package uploaded to the current pear.php.net
2002-05-26 : installer can upgrade itself
2002-06-13 : first version of Gtk installer
2002-07-11 : first version of Web installer


_________________
Jason
jsweat_php AT yahoo DOT com
Back to top
View user's profile Send private message
toma
Smarty Regular


Joined: 25 Apr 2003
Posts: 62

PostPosted: Thu May 15, 2003 7:15 pm    Post subject: Reply with quote

I know pear::db has been around a long time, but it's been activly developed, modified, tweeked since inception:
http://cvs.php.net/cvs.php/pear/DB

@Toma: Well, Pear is still a mess on Windows. Also, I have yet to be given a reasonable argument as to why people should prefer Pear over any other library. After reviewing what is available there, I don't see the big deal. Please correct my misconceptions by providing some concrete examples, etc.

80% of the sites I develop for my clients are deployed on windows servers (their choice, not mine). I have never ran into any issue with pear on windows nor have I seen anything which would make me think it's a 'mess'. Do you have any specific examples? I can't provide anything besides the code itself to back my claim, though. Do you have any examples that show pear as a 'mess' on windows?

I agree that pear vs any other db abstraction layer is a very difficult argument. I think personal preference will always be the main reason people use one layer vs another. Here's the reasons I like pear:
* Distrubuted with official php releases
* Activly developed (of course phplib was activly developed when I started using it years ago. leason learned: any project could be dropped by it's original authors at any time. I think pear will live longer because it's 'official' to php.)
* Clean syntax
* Never had a database ussue caused by pear. (I write my code to run against mssql, sybase, oracle, mysql, postgresql, and sybase sql anywhere (odbc). I never had to change my pear::db calls but I did need to add lines like $db->setOption('optimize', 'portability'); to accomodate for oracle).

I'm sure you could find someone else that could give the exact same reasons (except for included w/ php) for any other db abstraction layer, but the above is why I like pear.
Back to top
View user's profile Send private message Visit poster's website
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Thu May 15, 2003 7:32 pm    Post subject: Reply with quote

I use my own one, with result objects and caching Smile
Back to top
View user's profile Send private message
sweatje
Smarty Regular


Joined: 17 Apr 2003
Posts: 70
Location: Bettendorf, Iowa, USA

PostPosted: Thu May 15, 2003 7:36 pm    Post subject: Reply with quote

Another relativly spartan approach is eclipse.
_________________
Jason
jsweat_php AT yahoo DOT com
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Thu May 15, 2003 7:49 pm    Post subject: Reply with quote

@toma: sorry, I should have been more specific. Pear (on windows) has been broken since its inception. The current out-of-the-box state of Pear on *WINDOWS* is that:

1) it is not properly installed by default;
2) the command line tools don't work well;
3) it requires a dreadful amount of work to get things working even moderately "right";
4) requires very specific dir structures, unless you can figure out how things are "supposed" to be organized;
5) working installations are difficult to replicate;
6) many Pear packages do not work properly--or at all--on windows;
7) poor separation between platform specific files;
Cool confusing;

Bear in mind that I've been programming a LONG LONG time, so don't take these as newbie complaints. From what I've seen, all the effort in Pear has been going into the package system, and as of today, I am *far* from impressed. To me, the package system is just a bunch of layers that are supposedly providing some level of automation but in reality are not very functional. Nor does it seem to solve any real world problem (it looks like the Pear folks thought that a package system was mandatory because of their heritage). I wish that pear.php.net would simply allow one to download class code (and make it viewable online) so that it can be installed at your own whim. In an attempt to make things "simple" all the important details that people are likely to be interested in are hidden. For people like me, that's a big downside to Pear.

Lastly, dbx is a supported module that is bundled with PHP. It is FAR easier to get dbx running on any given system than Pear:Very HappyB. In fact, I'd say that dbx is the EASIEST abstraction layer to get running.
Back to top
View user's profile Send private message
toma
Smarty Regular


Joined: 25 Apr 2003
Posts: 62

PostPosted: Thu May 15, 2003 8:22 pm    Post subject: Reply with quote

1) it is not properly installed by default;
2) the command line tools don't work well;

I agree with these two, but 1. isn't necessary. I prefer to have a copy of pear under each project directory because once it's in place and working i have no reason to mess with it. 2. is right on, but the command line stuff isn't necessary for db abstraciton.

3) it requires a dreadful amount of work to get things working even moderately "right";

My SmartestSmartyPractices article will setup pear easily and the only work you would need to do is copy and paste that. Of course, you you want to roll your own global-type file, it may take you a bit to learn pear, but if you you look at that article you'll see there's not much code in there for setting up pear.

4) requires very specific dir structures, unless you can figure out how things are "supposed" to be organized;

The dir structure distributed with php is fine and no changes are necessary.

5) working installations are difficult to replicate;

I distribute pear with my projects rather than making people set it up indpendently. I think this statement is impossible to backup or disprove, however.

6) many Pear packages do not work properly--or at all--on windows;

Many pear packages are not necessary for db abstraction. I've also never encountered a pear package I wanted to use that didn't work on windows (this certianly doesn't mean some don't exist)

7) poor separation between platform specific files;
8) confusing;

7: never had to deal with any platform specific file that I can think of. Definatly no platform specific files are used in db abstraction.

8: er, every new class can be confusing. There's a learning curve associated with everything. I definatly would not call pear confusing. I don't think this point is valid under any context since it's not based on a clear fact...it's just personal knowledge of the system (e.g. I thought xsl was confusing when I started using it but that doesn't make it bad).

>>From what I've seen, all the effort in Pear has been going into the package system, and as of today, I am *far* from impressed.

Yea, me too, but the package system is very new (if by package you mean the installer thinger). I rarely use anything from pear that isn't part of the base distribution and db abstraction is totally contained in the base distribution.

Lastly, dbx is a supported module that is bundled with PHP. It is FAR easier to get dbx running on any given system than Pear::DB. In fact, I'd say that dbx is the EASIEST abstraction layer to get running.


Yea, I've looked at DBX. I would still recommend a wrapper for it though. While php is not an object oriented language (a point I try to stress to people), I think using objects in a db abstraction layer is the ideal method. I think using stand-alone functions (mysql_connect, dbx_connect, etc) is the wrong approach.
Back to top
View user's profile Send private message Visit poster's website
sweatje
Smarty Regular


Joined: 17 Apr 2003
Posts: 70
Location: Bettendorf, Iowa, USA

PostPosted: Thu May 15, 2003 8:43 pm    Post subject: Reply with quote

One additional consideration may be who is the target of your code? If it is an application that you have complete control over the PHP environment and web server, then a PHP extension is fine. If, on the other hand, you have an open source project, you can not rely on a particular PHP extension being available, and a pure PHP script based DB abstraction layer may be more appropriate.

Reasoning along these lines has be brought up with regards to converting a portion of Smarty to a PHP extension. This "feature" would do little good in most hosted configurations.
_________________
Jason
jsweat_php AT yahoo DOT com
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Thu May 15, 2003 8:48 pm    Post subject: Reply with quote

@toma: thanks for the reply. My comments concerned the overall Pear project, which is why some of the points didn't pertain to pear::db or which have broader implications than simply trying to get pear::db installed.

You are right--it is very possible to get JUST pear::db working since it is supplied with PHP. It is disheartening that you are reduced to bundling pear projects as sub-components of your own projects when it appears that one of the purposes of pear was to be a *common* package library. Never-the-less, I *prefer* the "statically linked" distribution method like the one you use. That's the way I do things too--it means things will just work.

I wasn't trying to bash Pear--I am hoping you (or someone else) will refute my points and show me the way Smile

Anyways, getting back to the abstraction discussion, I have to disagree with wrapping the dbx functions. dbx IS a wrapper. If you want to subclass it, you are likely not factoring your code properly. If the idea of wrapping dbx is that you might want to replace it one day, then you are really saying that everyone should roll their own wrapper for any db abstraction class they want to use--just in case the need arises to replace it. I don't buy that story.

DB abstraction is by its very nature something that isn't actually NEEDED for a given program -- it is needed for a maintenance plan (ie. I MAY want to swap dbs later). Adding more code layers to support the dubious notion that you "need" an abstracted abstraction layer is really pushing the envelope on anti-pragmatism. Especially since no abstraction layer is directly replacable by another one. That's one thing I wish there was more work on--a unified pattern for db abstraction classes.
Back to top
View user's profile Send private message
toma
Smarty Regular


Joined: 25 Apr 2003
Posts: 62

PostPosted: Thu May 15, 2003 9:01 pm    Post subject: Reply with quote

dbx_* wrapping was suggested because of the non-basic functionality you can put into a class when using an abstraction layer.

Here some php with pear and smarty code which should illustrate why I like the functions bundled with pear::db (and, therefore, like pear::db):
Code:

<?PHP
$t = new Smarty;
$t->assign('rows', $db->getAll('select * from table where ref_user=1'));
$t->assign('states', $db->getAssoc('select state_key, name from states order by name'));
$t->assign('username', $db->getOne('select name from users where user_key = 1'));


<html>
<body>
Hi {$username}<BR>
<BR>
{foreach from=$rows item=r}
  {$r.col1} - {$r.col2}<BR>
{/foreach}
<BR><BR>
<form method="get">
  <select name="state_key">
   {html_options options=$states}
  </select>
</form>

</body>
</html>


What would the above php code look like if coded with dbx_? How about adodb (I think adodb will look very similar, but not dbx_).

adodb and pear::db are, I think, very similar, but pear is part of php and that's the reason I prefer it over adodb specificly.
Back to top
View user's profile Send private message Visit poster's website
sweatje
Smarty Regular


Joined: 17 Apr 2003
Posts: 70
Location: Bettendorf, Iowa, USA

PostPosted: Thu May 15, 2003 9:13 pm    Post subject: Reply with quote

If you adopt a MVC mindset, I think the choice of db abstraction layer has even less of an impact.

I assign all Smarty variable in a View component. Since I am in View, there should be no sign of db calls anywhere. Similar to toma's code above, mine might look like:


Code:
$t = new Smarty;
$states = new States;

$t->assign(array(
    'rows' => $states->GetData()
   ,'states' => $states->GetList()
   ,'user' => User::GetName(1)
    );


So the impact of using or not using the db abstraction layer is limited to the Model Classes (States and User in the above example). By personal choise, it is ADOdb that I do end up using in my Model classes. My States::GetData method would be slightly longer than the one liner that toma posted, but that is becuase I always code for errors returned from the db calls in my Model classes that access databases.

HTH
_________________
Jason
jsweat_php AT yahoo DOT com
Back to top
View user's profile Send private message
toma
Smarty Regular


Joined: 25 Apr 2003
Posts: 62

PostPosted: Thu May 15, 2003 9:32 pm    Post subject: Reply with quote

sweatje wrote:
My States::GetData method would be slightly longer than the one liner that toma posted, but that is becuase I always code for errors returned from the db calls in my Model classes that access databases.

HTH


FYI, pear supplies a fantastic error handler. All db resutls are checked for errors and, if one is returned, an exception is thrown and the error handler checks it and processes as configured. Personally, I use a custom function and die() out with a print_r of my error object because there should never be a non-reallybad reason (like db is unavailable) for the db to return an error.

Pear::db is based on pear and pear provides additional functionality to the class. Error stuff is a big part of that.

An MVC mindset? not sure what you mean by this, but if you mean a class-based application, yea. however, I (as mentioned above) try to stress to people that php is not a class-based language and should not be used as such for ideal coding.

I've programmed php for 4 years now and I've tried several methods, including class-based, for my apps. I found class-based apps to be much harder to maintain in the long run in php.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> General All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP