[quote] I REALLY don't understand why anybody would abstract out every single table as a separate class like that. Surely there are some COMMON features and behaviours between the fields of any given MySQL type. [\quote] IMHO, the answer is simplicity of implementation and to some extent performance. If I have two tables with different layouts and names, using just one generic class to manipulate them will require that the class be implemented with additional and often complex logic to take care of the differences in the names and layouts of the tables. I personally find there is no advantage in doing that in terms of performance or maintenance. -----Original Message----- From: Richard Lynch [mailto:ceo@xxxxxxxxx] Sent: Thursday, June 23, 2005 11:41 PM To: Leila Lappin Cc: Evert | Rooftop; PHP-Users Subject: RE: Extra (persistant) tier On Wed, June 22, 2005 8:35 pm, Leila Lappin said: > When I worked with other OO languages, I usually designed my persistent > business objects in two levels. A level (lower level) designed and > implemented direct database calls. Each database table had a class > abstraction at this level which provided the database calls for saving, > loading and etc. At this level I also provided for the caching > considerations, i.e. if a table was already queried and a list was > available > the list in memory was used instead of querying again. I had a guy hired me to do that once. He had me budgeted for about a month to write all the classes. I spent two days writing a PHP script to write a PHP class for each table in the database, using mysql_* introspection functions instead. :-) He was pretty happy, since I saved him about $10,000, give or take. The project died long before he ever got to the point of having me do the next level... Which is just as well. I REALLY don't understand why anybody would abstract out every single table as a separate class like that. Surely there are some COMMON features and behaviours between the fields of any given MySQL type. Wouldn't it make a LOT more sense to have a single abstract class that, given a MySQL table-name, would provide an object cache of data structures that matched the table field names/types? Surely the "text" field in table "foo" isn't all that different from the "text" field in table "bar" at that level. Maybe that's just me being ornery. > The next level was where the business model was implemented. If a > business > object required information from three tables that related to each other > in > a certain way the load methods would access the objects from cached lists > in > three different classes (each representing a database table) and created > the > final list. At this stage the list was cached and also represented the > business logic. Woof. Now see, there, I gotta wonder is your cache really faster than a good single query? Cuz I'm thinking three separate queries for the data is gonna be a lot more expensive. Sure, maybe it's cached. Or maybe it's not. With the relatively SHORT life-time of a PHP script (you hope) the odds on any given datum being cached should be pretty LOW, I would think. Plus, the way this works out, you're probably going to end up having a separate query for every row if you are displaying, say, 10 "rows" of inter-related data from three tables. That's 30 queries instead of 1. That can't be faster than one well-written query. > Although I haven't done this in PHP I think with PHP5 it's possible. The > only challenge may be the caching of query results but I think Pear > modules > already have something about that. Caching query results should be relatively easy... Of course, your DATABASE server and your Operating System are *already* caching data for you. Will your cache on top of their cache really provide significant performance boost in PHP? Plus, if you design the Application Logic correctly, you shouldn't *HAVE* duplicate queries to get the same data in a single script. This whole data-cache thing might make sense in a language where there is a central shared cache (Java? JSP?) but in PHP I just don't see it being "all that" By the time you've filled up your cache with all the stuff you are going to re-use, the script should be FINISHING. PHP is not Java. The solutions that are great in Java aren't in PHP sometimes. And vice versa, of course. Now if you combine this with some kind of PHP Application Framework, and throw away the whole point of the cornerstone of the share-nothing architecture (which has pros and cons) then you might maybe have a significant performance increase... But there ain't such a beast yet, far as I know, though some folks are working on them. So, I gotta say, if you did this in PHP, you've made a fundamental error in assessing the performance/benefit/cost ratios of what makes a PHP Application fast. This is all just MY OPINION. I'm sure somebody is going to tell me just how stupid and naive I mussed be for not undersanding OO. Never mind I spent 15 years hacking in Common Lisp where damn near *everything* is an object and some of my OO code is still in production use 10 years after it was written. Somebody's bound to post how the maintainability would be SOOO much better it's worth the performance price. I disagree. I believe there are BETTER abstraction models for how PHP works than the "one class per db table". -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
