NYCPHP Meetup

NYPHP.org

[nycphp-talk] MySQL, MyISAM tables, <trigger> | <on delete cascade> - Help

Dan Cech dcech at phpwerx.net
Fri Feb 20 14:11:04 EST 2004


Phil Powell wrote:
> Dan Cech wrote:
>> My recommendation is to look at using a more powerful structure to 
>> represent the relationship between your departments.  Specifically I 
>> would recommend Joe Celko's Nested Sets or a variation thereof.
>>
>> You can find a lot of information in the archives of this list and the 
>> nyphp-dev list, and also plenty of resources on the net. A good place 
>> to start would be:
>>
>> <http://www.intelligententerprise.com/001020/celko.jhtml>
>>
>> This approach has many advantages, and would allow you to accomplish 
>> this type of delete quite efficiently, as well as offering additional 
>> ways to work with the data, such as a one-query answer to the problem 
>> of retrieving all ancestor or descendant departments.
>>
> Interesting.. I'll look into that more, but the article does not 
> indicate whether this approach works for a very simple MySQL 3.23 model 
> MyISAM table.  If it doesn't implementing this would be fine, provided 
> we tell every client that looks into our custom-built app to upgrade 
> everything from PHP and MySQL on down before they can use our app they 
> bought.

The differences between MySQL 4.x and 3.23.x are not that great when 
dealing with the simple SQL required for this type of system, and thus 
far in all my PHP work I haven't found a situation where you can't come 
up with a solution which will work with the 2 different flavours of 
MySQL.  Admittedly I try to restrict myself to code which will also 
function on PostgreSQL, Oracle and MSSQL, but my point is that the 
majority of problems can be solved without having to resort to vendor or 
release-specific SQL extensions, if that is what is required.

As for using a shell script to execute queries through the MySQL 
command-line client, my opinion is that it is a Bad Thing.  Admittedly 
you don't have the advantage of being able to use transactions anyway, 
but by designing your system this way you are not only breaking up what 
should really be an atomic database operation into several different 
parts, but also creating a solution which cannot be easily upgraded to 
take advantage of features such as transaction support.

Dan





More information about the talk mailing list