RE: [Phpgroupware-developers] adodb

[Alex Borges]

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
>