[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