DB classes in PHP 4: include file hell

[ooba gooba]

After doing some work in both Java and ASP.NET, I came back to add some
major enhancements to a PHP 4 application I built several years ago. A
lot of the database access is currently sprinkled throughout the
application.

In the Java and .NET worlds, I would do data access code by creating
classes that would handle all of the data access for each of the
application data entities. This worked great and kept all the data
access in one clearly designated set of classes.

I thought I would apply the same concept to PHP. However, it isn't
working well, and here's why:

- Because I'm using MySQL 4.1 and MyISAM tables (InnoDB is too darn
big), I have to manage all the relationships myself.

- If I need to delete an entity that has a lot of relationships, I have
to delete the records from all the related tables. I can do this by
either (a) making direct calls to MySQL to delete records from all the
related tables, or (b) if this was Java or .NET, I would simply make
calls to the related data objects. Since some of the related tables also
had related operations to perform, I started revising my PHP code to use
the latter method. So my code started to look like this:

class HcsDBO
{
// Delete an HCS and all its related records
function Delete($hcs)
{
if (!empty($hcs))
{
HospitalsDBO::D eleteHCSHospita ls($hcs);
UsersDBO::Delet eHCSUsers($hcs) ;
BillToDBO::Dele te($hcs);
DuesDBO::Delete ($hcs);

// Now delete the HCS record
global $db;
$sql = "DELETE FROM HCS WHERE EntityID=$hcs";
$db->Query($sql);
}
}
}

- In order to call these other data object methods, I need to include
their files. This means that whenever I need to perform any kind of HCS
operation, whether or not related tables are involved, I need to include
all the data access code for all the related tables. That's going to be
a LOT of code.

- Compiled (or pseudo-compiled) languages such as Java and .NET can pull
in called objects as needed. PHP doesn't. All that code is read and
parsed for every page that requires any of it.

I can't see that this approach is very efficient for PHP, but I don't
want to continue the "data access code is sprinkled everywhere"
approach. Unfortunately, the web host does not support PHP 5.

Is there a better solution, or should I revert to the "sql code
sprinkled everywhere" approach?

[Willem Bogaerts]

Re: DB classes in PHP 4: include file hell

- Because I'm using MySQL 4.1 and MyISAM tables (InnoDB is too darn

big), I have to manage all the relationships myself.

I run PHP and MySQL myself on an ancient home computer with win98 and
far too little disk space. It runs fine. With InnoDB, that is.

<snip>

- Compiled (or pseudo-compiled) languages such as Java and .NET can pull
in called objects as needed. PHP doesn't. All that code is read and
parsed for every page that requires any of it.
>
I can't see that this approach is very efficient for PHP, but I don't
want to continue the "data access code is sprinkled everywhere"
approach. Unfortunately, the web host does not support PHP 5.

Why not? PHP is an interpreter language. Loading things only when you
need them is quite efficient. If you use the require_once statement, you
can make sure that you don't define things twice with includes.

Be careful though, that PHP first tries to resolve relative paths
relative to the "browsed" file, not to the currently included file. Best
to use absolute paths only. So instead of:
require_once('. ./database.php');
you could write:
require_once(di rname(__FILE__) . '/../database.php');

There is no difference when you point your browser to that file, but
there is a difference when you include a file with the above contents
from another directory.

Best regards
--
Willem Bogaerts

Application smith
Kratz B.V.

http://www.kratz.nl/

[Toby A Inkster]

Re: DB classes in PHP 4: include file hell

ooba gooba wrote:

- Because I'm using MySQL 4.1 and MyISAM tables (InnoDB is too darn
big), I have to manage all the relationships myself.

Upgrade your hosting. Use MySQL 5, or switch to PostgreSQL, Oracle or
Microsoft SQL Server. Any of those can properly handle foreign keys and
cascaded deletes and handy things like that.

- If I need to delete an entity that has a lot of relationships, I have
to delete the records from all the related tables.

Upgrade your hosting. A decent database can do cascaded deletes. e.g.:

DELETE FROM users WHERE userid='frank';

can automatically remove, say, all entries in the "articles" table where
Frank was the author.

- In order to call these other data object methods, I need to include
their files. This means that whenever I need to perform any kind of HCS
operation, whether or not related tables are involved, I need to include
all the data access code for all the related tables. That's going to be
a LOT of code.

Don't include() the files until you know you're going to use them.

e.g. Don't do this:

include "foo-function.php";
if ($something)
{
foo($blah);
}

Do this:

if ($something)
{
include_once "foo-function.php";
foo($blah);
}

Then your file only gets included if it's needed. Contrary to popular
wisdom, include() and require() statements do not need to be at the top of
your file, and there is usually no advantage in putting them there.

- Compiled (or pseudo-compiled) languages such as Java and .NET can pull
in called objects as needed. PHP doesn't. All that code is read and
parsed for every page that requires any of it.

Upgrade your hosting. PHP 5 has class autoloading.

http://www.php.net/autoload

So if you do something like:

<?php $obj = new MyClass(); ?>

and MyClass has not yet been defined, then it will automatically call a
function __autoload() passing 'MyClass' as the parameter. You can define
the __autoload() function yourself, so that it does something useful like:

<?php
function __autoload ($c)
{ require_once $c.'.class.php' ; }
?>

or whatever your naming convention is.

I can't see that this approach is very efficient for PHP, but I don't
want to continue the "data access code is sprinkled everywhere"
approach. Unfortunately, the web host does not support PHP 5.
>
Is there a better solution, or should I revert to the "sql code
sprinkled everywhere" approach?

The better solution is to switch to a decent host that gives you better
tools to work with, including an ACID database that supports foreign keys
and cascading, and a recent version of PHP. The amount of effort saved by
switching to a more functional programming environment should more than
outweigh the effort involved in switching web hosts.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[Jerry Stuckle]

Re: DB classes in PHP 4: include file hell

ooba gooba wrote:

After doing some work in both Java and ASP.NET, I came back to add some
major enhancements to a PHP 4 application I built several years ago. A
lot of the database access is currently sprinkled throughout the
application.
>
In the Java and .NET worlds, I would do data access code by creating
classes that would handle all of the data access for each of the
application data entities. This worked great and kept all the data
access in one clearly designated set of classes.
>
I thought I would apply the same concept to PHP. However, it isn't
working well, and here's why:
>
- Because I'm using MySQL 4.1 and MyISAM tables (InnoDB is too darn
big), I have to manage all the relationships myself.
>

You get some and you lose some. You'll need to use InnoDB tables to get
the MySQL to handle the relationships. But I've found it really isn't
that bad.

- If I need to delete an entity that has a lot of relationships, I have
to delete the records from all the related tables. I can do this by
either (a) making direct calls to MySQL to delete records from all the
related tables, or (b) if this was Java or .NET, I would simply make
calls to the related data objects. Since some of the related tables also
had related operations to perform, I started revising my PHP code to use
the latter method. So my code started to look like this:
>
class HcsDBO
{
// Delete an HCS and all its related records
function Delete($hcs)
{
if (!empty($hcs))
{
HospitalsDBO::D eleteHCSHospita ls($hcs);
UsersDBO::Delet eHCSUsers($hcs) ;
BillToDBO::Dele te($hcs);
DuesDBO::Delete ($hcs);
>
// Now delete the HCS record
global $db;
$sql = "DELETE FROM HCS WHERE EntityID=$hcs";
$db->Query($sql);
}
}
}
>
- In order to call these other data object methods, I need to include
their files. This means that whenever I need to perform any kind of HCS
operation, whether or not related tables are involved, I need to include
all the data access code for all the related tables. That's going to be
a LOT of code.
>

Yep, that's true. But the interpreter is pretty good.

- Compiled (or pseudo-compiled) languages such as Java and .NET can pull
in called objects as needed. PHP doesn't. All that code is read and
parsed for every page that requires any of it.
>
I can't see that this approach is very efficient for PHP, but I don't
want to continue the "data access code is sprinkled everywhere"
approach. Unfortunately, the web host does not support PHP 5.
>
Is there a better solution, or should I revert to the "sql code
sprinkled everywhere" approach?

Either use require_once() to get them when you need them (which is why I
do - with no noticeable effect on performance) or go to InnoDB tables.


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===