Re: [Phpgroupware-developers] adodb

[Chris Weiss]

I fully agree with both of you, but I think this was an example of
what CAN be done, there are cases when this kind of thing needs to be
done, but not for a case as simple as this example :)


On Tue, 23 Nov 2004 17:08:08 -0600, Alex Borges <address@hidden> wrote:
> On Tue, 2004-11-23 at 14:58 +0100, Philipp Kamps wrote:
> 
> 
> > Hi sigurdne,
> >
> > your example will work because you get the resultSet
> > (not the db object) into $dbresult/$dbresults2.
> >
> > Generally I would say in case you use two loops
> > of resultSets you will be able to optimize your
> > sql statements to one single on.
> > Which is a lot more performant and easier to read
> > in the code.
> > We propably would improve phpgroupware if we change
> > this.
> > 
> Absolutely agree. This should be  on an official style document. Many
> scalability problems come from this kind of thing.
> 
> I guess the general point is to try to pass as much number crunching,
> sorting and search loops to the database which is supposed to be
> optimized for it.
> 
> That way its much easyer to find scalability problems and throw indexes
> at them which also tends to work fine.
> 
> So, this nested loop will probably happen in the database, but if its
> using indexed lookups on the joined table, then it will be much faster
> than any for, foreach or while we can do in php. This gap in speed
> increases proportionaly to the size of the data.
> 
> If the search is very complex, good databases will let us make indexes
> on searches (indexed views, functions or some proprietary ways to index
> a regex match and stuff like that).
> 
> Database normalization generally leads to this same conclusion as most
> of the middle/front end code neednt have nesting when its operating on
> data brought from the database to construct another dataset because most
> (if not all) of the would-be loops are relationships in the database
> (joins-on in sql, just as fips says).
> 
> If the program needs to do this kind of operation, its because we are
> lacking a relationship between tables (another table or
> imported/exported key) that we probably should have, or an existing
> relationship is being olimpically (and incorrectly) ignored by us, the
> developer, or both.
> 
> 
> 
> 
> > Thanks for your feedback.
> >
> > Cheers, fips
> >
> > P.S. Setup with adodb is running now.
> >
> > Am Di, den 23.11.2004 schrieb sigurdne um 14:00:
> > > adodb is used in the proposal-branch like this:
> > >
> > > $dbresult = $GLOBALS['phpgw']->db->Execute("SELECT column_name from ...");
> > > while (!$dbresult->EOF)
> > > {
> > >  $dbresult2 = $GLOBALS['phpgw']->db->Execute("SELECT " .
> > > $dbresult->fields['column_name'] . "from ...");
> > >  while (!$dbresult2->EOF)
> > >  {
> > >   $list[] = $dbresult2->fields[$dbresult->fields['column_name']];
> > >   $dbresult2->MoveNext();
> > >  }
> > >  $dbresult->MoveNext();
> > > }
> > >
> > > Sigurd
> > >
> > > >===== Original Message From Philipp Kamps <address@hidden> =====
> > > >Hi ya'll,
> > > >
> > > >this time in english ;-)
> > > >
> > > >Patch 3496 includes adodb to the api.
> > > >========================================
> > > >
> > > >You may access this new object by using
> > > >$GLOBALS['phpgw']->adodb.
> > > >
> > > >The original db layer
> > > >(class.db.inc.php - $GLOBALS['phpgw']->db)
> > > >is still valid.
> > > >I changed the original db layer in a way that
> > > >it internally uses adodb.
> > > >
> > > >Adodb supports _a lot_ of different database
> > > >systems:
> > > >http://phplens.com/adodb/supported.databases.html
> > > >
> > > >So far for the good news.
> > > >=========================================
> > > >
> > > >Practically phpgw _won't_ run on so much different
> > > >database systems. One import reason is the use of
> > > >reserved key words for some database systems
> > > >(http://wiki.phpgroupware.org/index.php?page=SQL+reserved+key+words)
> > > >
> > > >In order to make the transparent db layer (class.db.inc.php)
> > > >working we have to adapt phpgroupware:
> > > >
> > > >- a direct access to the objects vars won't be able
> > > >  ($GLOBALS['phpgw']->db->Record)
> > > >
> > > >- adodb uses a singleton class to return one unique object
> > > >  Following code will fail:
> > > >  $db2 = $GLOBALS['phpgw']->db;
> > > >  $GLOBALS['phpgw']->db->query('blabla');
> > > >  while($GLOBALS['phpgw']->nextRecord)
> > > >  {
> > > >     $db2->query('blubblub');
> > > >  }
> > > >
> > > >- I haven't found the according methods lock/unlock as methods
> > > >  in adodb.
> > > >
> > > >Additional notes:
> > > >==========================================
> > > >
> > > >- $GLOBALS['phpgw']->adodb is a reference to
> > > >  $GLOBALS['phpgw']->db->adodb
> > > >
> > > >- class.db.inc.php as transparent db layer isn't finished. I
> > > >  still have to impliment some methods.
> > > >
> > > >- I was able to setup a new phpgroupware. But I'm pretty sure
> > > >  that some parts of the install routine isn't working properly.
> > > >
> > > >- Most modules were able to come up with their index page.
> > > >  But they fail on some other pages. This is because of the
> > > >  reasons I wrote before.
> > > >
> > > >- All original db drivers (class.db_sql.inc.php) will not
> > > >  be necessary anymore.
> > > >
> > > >Cheers, fips
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Phpgroupware-developers mailing list
> > > >address@hidden
> > > >http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> > >
> > >
> > >
> > > _______________________________________________
> > > Phpgroupware-developers mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> > --
> > Philipp Kamps
> > - Team Softwareentwicklung -
> > pro|business AG
> > Expo Plaza 1
> > 30539 Hannover
> > Telefon    05 11 / 6 00 66 - 333
> > Telefax    05 11 / 6 00 66 - 355
> > E-Mail     address@hidden
> >
> > *******************************************
> >                  eMail Management -
> > Wege aus der eMail-Flut, Rechte & Pflichten
> >
> > Unser Thema am 24.11.2004 in Hannover
> > und am 25.11.2004 in Frankfurt
> >
> > Mehr dazu unter www.probusiness.de/aktuelles/
> > *******************************************
> >
> >
> >
> > _______________________________________________
> > Phpgroupware-developers mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> >
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> 
>