NYCPHP Meetup

[Phil Powell]

Dan Cech wrote:

> 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
>
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>
You do have a point.. I guess I just can't think of a solution that 
would fit the current environment.  However,  I would think that 
allowing for futuristic transactional support is in order by providing 
OO-level switches that determine the flavor of your MySQL and act 
accordingly.

Sorry, but I don't understand the term "atomic" in this case.

Phil

-- 
Phil Powell
Web Developer
  ADNET Systems, Inc.
  11260 Roger Bacon Drive, Suite 403
  Reston, VA  20190-5203
Phone: (703) 709-7218 x107   Cell: (571) 437-4430   FAX: (703) 709-7219
EMail:  Phillip.Powell at adnet-sys.com      AOL IM: SOA Dude